166.htm

unix高级编程原吗

  <br>
        (Question suggested by Michael T. Stolarchuk <[e-mail]> <br>
        along with some suggestions for the answer.) <br>
  <br>
  <br>
            Network diagnostics such as the verification of a <br>
            network's setup, examples are tools like arp, that report <br>
            the ARP messages sent from hosts. <br>
  <br>
            Reconstruction of end to end sessions. tcpshow attempts <br>
            to do this, but more sophisticated examples are the array <br>
            of security tools which try to keep tabs on network <br>
            connections. <br>
  <br>
            Monitoring network load. Probably one of the most <br>
            practical uses, a lot of commercial products usually use <br>
            specialized hardware to accomplish this. <br>
  <br>
        1.7) Will I have to replace any packets captured off the <br>
        network? <br>
  <br>
        -------------------------------------------------------------- <br>
  <br>
  <br>
        No, the packet capturing facilities mentioned make copies of <br>
        the packets, and do not remove them from the system's TCP/IP <br>
        stack. If you wish to prevent packets from reaching the <br>

        TCP/IP stack you need to use a firewall, (which should be <br>
        able to do packet filtering). Don't confuse the packet <br>
        filtering done by packet capturing facilities with those done <br>
        by firewalls. They serve different purposes. <br>
  <br>
        1.8) Is there a portable API to send raw packets into a <br>
        network? <br>
  <br>
        -------------------------------------------------------------- <br>
  <br>
  <br>
        Yes, route <[e-mail]> maintains Libnet, a library <br>
        that provides an API for low level packet writing and <br>
        handling. It serves as a good compliment for libpcap, if you <br>
        wish to read and write packets. The project's webpage can be <br>
        found at: <br>
  <br>
        http://www.packetfactory.net/libnet/ <br>
  <br>
        1.9) Are there any high level language APIs (Not C) for raw <br>
        IP access? <br>
  <br>
  <br>
        -------------------------------------------------------------- <br>
  <br>
  <br>
        A PERL module that gives access to raw sockets is available <br>
        at: <br>
  <br>
        http://quake.skif.net/RawIP/ <br>
  <br>
        A Python library "py-libpap" can be found at: <br>
  <br>
        ftp://ftp.python.org/pub/python/contrib/Network/ <br>
  <br>
    2) RAW socket questions: <br>
    ------------------------ <br>
  <br>
        2.1) What is a RAW socket? <br>
        -------------------------- <br>
  <br>
        The BSD socket API allows one to open a raw socket and bypass <br>
        layers in the TCP/IP stack. Be warned that if an OS doesn't <br>
        support correct BSD semantics (correct is used loosely here), <br>
        you're going to have a hard time making it work. Below, an <br>

        attempt is made to address some of the bugs or surprises <br>
        you're in store for. On almost all sane systems only root <br>
        (superuser) can open a raw socket. <br>
  <br>
        2.2) How do I use a raw socket? <br>
        ------------------------------- <br>
  <br>
            2.2.1) How do I send a TCP/IP packet through a raw <br>
            socket? <br>
  <br>
            ---------------------------------------------------------- <br>
  <br>
  <br>
            Depending on what you want to send, you initially open a <br>
            socket and give it its type. <br>
  <br>
            sockd = socket(AF_INET,SOCK_RAW,<protocol>); <br>
  <br>
            You can choose from any protocol including IPPROTO_RAW. <br>
            The protocol number goes into the IP header verbatim. <br>
            IPPROTO_RAW places 0 in the IP header. <br>
  <br>
  <br>
            Most systems have a socket option IP_HDRINCL which allows <br>
            you to include your own IP header along with the rest of <br>
            the packet. If your system doesn't have this option, you <br>
            may or may not be able to include your own IP header. If <br>
            it is available, you should use it as such: <br>
  <br>
  <br>
            char on = 1; <br>
            setsockopt(sockd,IPPROTO_IP,IP_HDRINCL,&on,sizeof(on)); <br>
  <br>
            Of course, if you don't want to include an IP header, you <br>
            can always specify a protocol in the creation of the <br>
            socket and slip your transport level header under it. <br>
  <br>
            You then build the packet and use a normal sendto(). <br>
  <br>
            2.2.2) How do I build a TCP/IP packet? <br>
            -------------------------------------- <br>
  <br>
            Examples can be found at http://www.whitefang.com/rin/ <br>
            which attempt to illustrate the details involved. They <br>
            also illustrate some of the bugs mentioned below. <br>

  <br>
            Briefly, you need to actually write the packet out in <br>
            memory and hand it over to the socket where it will <br>
            hopefully fire it away and await more packets. <br>
  <br>
            2.2.3) How can I listen for packets with a raw socket? <br>
            ------------------------------------------------------ <br>
  <br>
            Traditionally the BSD socket API did not allow you to <br>
            listen to just any incoming packet via a raw socket. <br>
            Although Linux (2.0.30 was the last version I had a look <br>
            at), did allow this, it has to do with their own <br>
            implementation of the TCP/IP stack. Correct BSD semantics <br>
            allow you to get some packets which match a certain <br>
            category (see below). <br>
  <br>
            There's a logical reason behind this; for example TCP <br>
            packets are always handled by the kernel. If the port is <br>
            open, send a SYN-ACK and establish the connection, or <br>
            send back a RST. On the other hand, some types of ICMP (I <br>
            compiled a small list below), the kernel can't handle. <br>
            Like an ICMP echo reply, is passed to a matching raw <br>

            socket, since it was meant for a user program to receive <br>
            it. <br>
  <br>
            The solution is to firewall that particular port if it <br>
            was a UDP or TCP packet, and sniff it with a packet <br>
            capturing API (a list is mentioned above). This prevents <br>
            the TCP/IP stack from handling the packet, thus it will <br>
            be ignored and you can handle it yourself without <br>
            intervention. <br>
  <br>
            If you don't firewall it, and reply yourself you'll wind <br>
            up having additional responses from your operating <br>
            system! <br>
  <br>
            Here's a concise explanation of the semantics of a raw <br>
            BSD socket, taken from a Usenet post by W. Richard <br>
            Stevens <br>
  <br>
            From <[e-mail]> (Sun Jul 6 12:07:07 1997) : <br>
  <br>
            "The semantics of BSD raw sockets are: <br>
  <br>
  <br>
            -  TCP and UDP: no one other than the kernel gets these. <br>
  <br>
            -  ICMP: a copy of each ICMP gets passed to each matching raw <br>
               socket, except for a few that the kernel generates the reply <br>
               for: ICMP echo request, timestamp request, and mask request. <br>
  <br>
            -  IGMP: all of these get passed to all matching raw sockets. <br>
  <br>
            -  all other protocols that the kernel doesn't deal with (OSPF, <br>
               etc.): these all get passed to all matching raw sockets." <br>
  <br>
            After looking at the icmp_input() routine from the <br>
            4.4BSD's TCP/IP stack, it seems the following ICMP types <br>
            will be passed to matching raw sockets: <br>
  <br>
                Echo Reply: (0) <br>
  <br>
                Router Advertisement (9) <br>
  <br>
                Time Stamp Reply (13) <br>
  <br>
                Mask Reply (18) <br>

  <br>
  <br>
        2.3) What bugs should I look out for when using a raw socket? <br>
        ------------------------------------------------------------- <br>
  <br>
            2.3.1) IP header length/offset host/network byte <br>
            (feature/bug?) <br>
  <br>
            ---------------------------------------------------------- <br>
  <br>
  <br>
            Systems derived from 4.4BSD have a bug in which the <br>
            ip_len and ip_off members of the ip header have to be set <br>
            in host byte order rather than network byte order. Some <br>
            systems may have fixed this. I've confirmed this bug has <br>
            been fixed on OpenBSD 2.1. <br>
  <br>
            2.3.2) Unwanted packet processing on some systems. <br>
            -------------------------------------------------- <br>
  <br>
            Thanks to Michael Masino <[e-mail]> , Lamont <br>
            Granquist <[e-mail]> , and route <br>

            <[e-mail]> for the submission of bug reports. <br>
  <br>
            Some systems will process some of the fields in the IP <br>
            and transport headers. I've attempted to verify the <br>
            reports I've received here's what I can verify for sure. <br>
  <br>
            Solaris (at least 2.5/2.6) and changes the IP ID field, <br>
            and adds a Do Not Fragment flag to the IP header (IP_DF). <br>
            It also expects the checksum to contain the length of the <br>
            transport level header, and the data. <br>
  <br>
            Further reports which I cannot verify (can't reproduce), <br>
            consist of claims that Solaris 2.x and Irix 6.x will <br>
            change the sequence and acknowledgment numbers. Irix 6.x <br>
            is also believed to have the problem mentioned in the <br>
            previous paragraph. If you experience these problems, <br>
            double check with the example source code. <br>
  <br>
            You'll save yourself a lot of trouble by just getting <br>
            Libnet http://www.packetfactory.net/libnet/ <br>
  <br>
        2.4) What are raw sockets commonly used for? <br>

        -------------------------------------------- <br>
  <br>
        Various UNIX utilities use raw sockets, among them are: <br>
        traceroute, ping, arp. Also, a lot of Internet security tools <br>
        make use of raw sockets. However in the long run, raw sockets <br>
        have proven bug ridden, unportable and limited in use. <br>
  <br>
    3) libpcap (A Portable Packet Capturing Library) <br>
    ------------------------------------------------ <br>
  <br>
        3.1) Why should I use libpcap, instead of using the native <br>
        API on my operating system for packet capturing? <br>
  <br>
        -------------------------------------------------------------- <br>
  <br>
  <br>
        libpcap was written so that applications could do packet <br>
        capturing portably. Since it's system independent and <br>
        supports numerous operating systems, your packet capturing <br>
        application becomes more portable to various other systems. <br>
  <br>
        3.2) Does libpcap have any disadvantages, which I should be <br>

        aware of? <br>
  <br>
        -------------------------------------------------------------- <br>
  <br>
  <br>
        Yes, libpcap will only use in-kernel packet filtering when <br>
        using BPF, which is found on BSD derived systems. This means <br>
        any packet filters used on other operating systems which <br>
        don't use BPF will be done in user space, thus losing out on <br>
        a lot of speed and efficiency. This is not what you want, <br>
        because packet loss can increase when sniffing a busy <br>
        network. <br>
  <br>
        DEC OSF/1 has an API which has been extended to support <br>
        BPF-style filters; libpcap does utilize this. <br>
  <br>
        In the future, libpcap may translate BPF style filters to <br>
        other packet capturing facilities, but this has not been <br>
        implemented yet as of version 0.3 <br>
  <br>
        Refer to question 1.4 to see how packet filters help in <br>
        reliably monitoring your network. <br>

  <br>
        3.3) Where can I find example libpcap source code? <br>
        -------------------------------------------------- <br>
  <br>
        A lot of the source code found at LBNL's ftp archive <br>
        ftp://ftp.ee.lbl.gov/ uses libpcap. More specifically, <br>
        ftp://ftp.ee.lbl.gov/tcpdump.tar.Z probably demonstrates <br>
        libpcap to a large extent. <br>
  <br>
    4) List of contributors. <br>
    ------------------------ <br>
  <br>
      Thamer Al-Herbish <[e-mail]> <br>
      W. Richard Stevens <[e-mail]> <br>
      John W. Temples (III) <[e-mail]> <br>
      Michael Masino <[e-mail]> <br>
      Lamont Granquist <[e-mail]> <br>
      Michael T. Stolarchuk <[e-mail]> <br>
      Mike Borella <[e-mail]> <br>
      route <[e-mail]> <br>
      Derrick J Brashear <[e-mail]> <br>
</small><hr>
<p align="center">[<a href="index.htm">回到开始</a>][<a href="155.htm">上一层</a>][<a href="167.htm">下一篇</a>]
<p align="center"><a href="http://cterm.163.net">欢迎访问Cterm主页</a></p>
</table>
</body>
</html>