RAW-sockets详解：底层数据传输的透明编程入门

需积分: 7 186 浏览量更新于2024-07-18 收藏 1.03MB PDF 举报

本文档是一份关于RAW套接字编程及其相关PACKET套接字技术的入门指南。RAW套接字是互联网套接字类型的一种补充，区别于传统的DATAGRAM和STREAM套接字。它们提供了一种底层的访问方式，使开发者能够直接查看和操作用于数据传输的原始信息，而不像 STREAM或DATAGRAM套接字那样封装了这些细节。首先，RAW套接字的使用涉及多个操作系统平台，包括Windows、Linux和Unix。在不同的操作系统上，编程接口API有所不同。在Windows中，开发人员需要熟悉Winsock API，这是其网络编程的基础；在Linux和Unix系统中，通常使用Berkeley Socket API，它提供了更为灵活的套接字选项和更深层次的数据控制。 RAW套接字主要应用于以下场景： 1. **网络监测与分析**：由于可以直接访问数据包，RAW套接字常用于网络监控工具，如嗅探器，用于分析和捕获网络流量，以便于网络安全分析、性能优化或诊断网络问题。 2. **网络设备驱动开发**：硬件设备可能需要直接操控网络数据，例如网络交换机或路由器，这时RAW套接字就非常有用，因为它们可以绕过常规的用户空间应用层协议栈。 3. **高性能数据传输**：对于对数据完整性和速度有极高要求的应用，比如游戏服务器或实时通信系统，RAW套接字可以提供更低的延迟和更高的吞吐量。 4. **协议实现和测试**：在实现自定义协议或者测试现有协议时，使用RAW套接字可以帮助开发者深入理解底层数据结构和交互过程。 5. **网络安全实验**：学习者可以通过RAW套接字进行网络安全实践，如创建自定义协议栈或实现简单的入侵检测系统。在使用RAW套接字编程时，开发者需要注意以下几点： - **权限限制**：由于RAW套接字提供了底层访问，它们通常需要更高的权限，如root权限，在Linux中使用它们可能需要sudo。 - **数据处理**：直接操作数据可能会涉及到二进制数据处理，开发者需要具备一定的网络协议理解和编码/解码能力。 - **错误处理**：由于直接操作网络数据，错误处理和异常处理至关重要，可能涉及到IP头校验、数据包排序等问题。 - **安全考虑**：不当使用RAW套接字可能导致数据泄露或恶意攻击，因此在设计安全策略时要格外小心。本文档提供了一个关于RAW套接字编程的全面入门，帮助读者理解和掌握这一强大工具，以便在实际项目中充分利用它们来满足各种网络应用的需求。

3 Programming with the APIs

3.1 General

We start by discussing some general topics that have to be considered for the development with any of the following

APIs. Other than the topics presented here, it should be noted that the programmer also has to observe the

particularities of the network protocols he wants to use. If these are not observed, like for example the correct order

in that protocol information has to be exchanged, it cannot be ensured that we are able to communicate with the

other host since the results than can be very diﬀerent based on the implementation of the the target host.

3.1.1 Byte Order

In network communication the byte-order, also known as endianness, is essential for setting and interpreting the

ﬁelds correctly. It comes into play whenever a value does need more than 1 byte of storage space. Whenever this

is the case we have to translate between network-byte-order and host-byte-order. The network-byte-order and host-

byte-order may may be diﬀerent depending on the used protocol and operating system. For the IP-protocol the

network-byte-order is big-endian, so we have to translate whenever the byte-order of the host is not big-endian [5].

So we have two cases:

• When we send network packets all data that needs more than 1 byte it has to be translated from host-byte-order

to network-byte-order.

• When we receive data on a socket all data that needs more than 1 byte it has to be translated from network-

byte-order to host-byte-order.

For the transformations used for the IP-protocol the Berkeley socket API provides a set of standard functions

which are available in the header ﬁle <arpa/inet.h>:

Function Description

uint32_t htonl(uint32_t hostlong) host-to-network

uint16_t htons(uint16_t hostshort) host-to-network

uint32_t ntohl(uint32_t netlong) network-to-host

uint16_t ntohs(uint16_t netshort) network-to-host

Table 1: Byte-Order Transformation Functions [8]

With Linux we can be sure that the data receive/sent over a socket always is in network-byte-order [5].

For Unix it can be the case that some ﬁelds of the header are in host-byte-order depending of the release (for

example BSD) [5].

3.1.2 Checksum

Many protocols used for network communication use a checksum to be able to detect transmission errors. There are

diﬀerent ways to calculate a checksum. If we choose to generate the packet headers completely by our self we have

to calculate and set the applicable header ﬁelds manually. There are some points to take into consideration if we do

this:

• Which algorithm has to be used to compute the checksum.

• Which ﬁelds of the header, sometimes even of multiple headers, have to be included in the calculation of the

checksum [5]. Of course the user data might have to be included in the calculation as well.

• If we want to calculate the checksum all header information already has to be set with the correct data.

• Do we have to calculate the checksum or can it be calculated automatically by the network driver/hardware

(for example the Ethernet checksum), the operating system or a predeﬁned function call [5].

As a possible code example for the calculation of a checksum here is the listing for computing the Internet-checksum

which was provided with the RFC 1071 which can be found in the appendix.

3.1.3 Type-Casting

One of the basic functionalities of the C programming language is that it supports Type-Casting. The ability to

cast binary data to a data structure struct in C is essential to make working with header data easier for the

programmer. To perform type casting we simply create a pointer to the desired structure:

struct header

protocolHeader;

Then we do need a pointer to the memory space where the binary data of the packet is stored, in our examples

mostly a char-Array with a ﬁxed SIZE[5]:

char buffer[SIZE];

Finally we can cast the binary data to our struct and afterwards are able to access the header ﬁelds[5]:

protocolHeader = (struct header

) buffer;

When accessing the header-ﬁeld we still have to take care of the byte order like mentioned before. For the majority

of the well known protocols there are predeﬁned structs available in the header ﬁles included in the libraries. Some

of the available headers are shown in the table below, but it does only show a part of the available header structures.

More headers may be available depending on the operating system and the library.

Linux Under Linux typically the following header ﬁles are available:

Header-File Description

<netinet/ip.h> Deﬁnes macros, variables, and structures for IP.

<netinet/ip_icmp.h> Deﬁnes macros, variables, and structures for ICMP.

<netinet/udp.h> Deﬁnes macros, variables, and structures for UDP.

<netinet/tcp.h> Deﬁnes macros, variables, and structures for TCP.

<netns/idp.h> Deﬁnes IPX packet headers.

<netns/sp.h> Deﬁnes SPX packet header.

<ssl.h> Deﬁnes SSL prototypes, macros, variables, and structures.

Table 2: C-Header-Files for Network Headers [8]

3.1.4 Header-Positions

Another issue that has to be taken into consideration is the position of the packet headers in the binary data. The

following has to be taken into consideration:

• Like it was shown in the beginning the header of a lower layer always encapsulate the header of the higher

layers and the data.

• The header of the lowest layer can always be found at the beginning of the binary data packet. It might be

the case that not all ﬁelds are present, for example this is the case for the Ethernet-Protocol in the Data Link

layer. For the Ethernet-Protocol the preamble, start of frame delimiter and the frame checksum are removed

by the network driver since they do belong more to the Physical Layer (OSI Layer 1)[5].

• If we type cast binary data to structs we have to add the length of the last header to the data pointer to get

the beginning of the next header [5]:

next_header = (struct header

) (buffer + sizeof(struct header));

• To ﬁnd the correct start position might be a bit more diﬃcult than a simple add operation as shown here if

the last header has a variable length with optional ﬁelds (like for example the IP-header or the TCP-header).

In that case we must ﬁrst get the ﬁxed part of the header, then access the length ﬁeld and ﬁnally compute the

length of the optional header. Only after doing this we are able to ﬁnd the start of the next header. If we are

interested in the content of the optional ﬁelds we also have to access the header ﬁeld containing the type of

optional ﬁelds and cast it to the correct type accordingly.

3.2 RAW-sockets

The ﬁrst API discussed here is the RAW-socket. It is available on Linux and Unix Systems. As already mentioned

the PACKET-sockets can be seen as a specialized form of RAW-sockets and just allow access a lower layer then the

normal RAW-socket. RAW-sockets allow access to the Network (OSI layer 4) and Internet (OSI layer 3) layer of the

network stack [5]. The use of RAW-sockets is limited to processes with an eﬀective user ID of 0 or the CAP_NET_RAW

capability since they require root-access permissions [1]. In the following we will start by giving a generic overview

over the functions available and necessary to create and work with RAW-sockets. After that we show the structure

of diﬀerent protocol level write and read operations.

3.2.1 socket()

Both the read and write to a RAW-socket require the socket to be created ﬁrst. For the creation of a socket the

same function as for normal sockets is used. It is available in the <netinet/in.h> header and has the following

form [8]:

int socket(int family, int type, int protocol)

The following parameters have to be deﬁned:

• family expects a constant value that describes the used address family [8]. The following values are deﬁned

in <sys/socket.h>:

Constant Description

AF_LOCAL Local communication

AF_UNIX Unix domain sockets

AF_INET IP version 4

AF_INET6 IP version 6

AF_IPX Novell IPX

AF_NETLINK Kernel user interface device

AF_X25 Reserved for X.25 project

AF_AX25 Amateur Radio AX.25

AF_APPLETALK Appletalk DDP

AF_PACKET Low level packet interface

AF_ALG Interface to kernel crypto API

Table 3: Address family constants provided in <sys/socket.h>

[8]

The function only passes errors originating from the network to the user when the socket is connected. In that

case only EMSGSIZE and EPROTO are passed for compatibility. If the IP_RECVERR ﬂag is enabled, all network

errors are saved in the error queue. It returns a non-negative socket-descriptor if it was created successful and

-1 if an error occurred during creation of the socket. Additionally the variable errno deﬁned in <errno.h>

is set and can have the following values [8]:

Flag Description

EACCES User tried to send to a broadcast address without having the broadcast ﬂag set on the

socket.

EFAULT An invalid memory address was supplied.

EINVAL Invalid argument.

EMSGSIZE Packet too big. Either Path MTU Discovery is enabled or the packet size exceeds the

maximum allowed IPv4 packet size of 64KB.

EOPNOTSUPP Invalid ﬂag has been passed to a socket call.

EPERM The user doesn’t have permission to open raw sockets.

EPROTO An ICMP error has arrived reporting a parameter problem.

Table 4: Errno ﬂags for socket() as deﬁned in <errno.h> [8]

Users have to be aware that setting the family of course also inﬂuences which protocol can be chosen later.

The usual option to use with RAW-sockets is the AF_INET to send and receive IP version 4 packets.

• type deﬁnes the socket type. The following values are deﬁned in <sys/socket.h>:

Constant Description

SOCK_STREAM Stream (connection) socket

SOCK_DGRAM Datagram (connection-less) socket

SOCK_RAW RAW socket

SOCK_RDM Reliably-delivered message

SOCK_SEQPACKET Sequential packet socket

SOCK_PACKET Linux speciﬁc way of getting packets at the dev level.

Table 5: The socket types are deﬁned in <sys/socket.h>[8]

Since we want to work with RAW-sockets we only use the SOCK_RAW constant in the following sections.

From Linux kernel 2.6.27, there is a second purpose for the type argument, it additionally allows to modify the

behavior of the socket by including the following options with bit-wise OR [8]:

– SOCK_NONBLOCK: Sets the O_NONBLOCK ﬁle status ﬂag on the new open socket descriptor. Using this

changes the socket to a non-blocking one.

– SOCK_CLOEXEC: Sets the close-on-exec ﬂag for the new socket descriptor. Useful if the program creates

child processes which use exec() to run another program. In that case this ﬂag will prevent the other

program from using this socket descriptor.

• protocol deﬁnes like the name implies the protocol of the packets that can be sent and received with the

socket [8]. The protocol numbers are deﬁned by the IANA (Internet Assigned Numbers Authority) and a

complete list can be found on their website. The table ?? shows the constants for protocols which are deﬁned

in the <netinet/in.h> header ﬁle.

Again, users have to be aware of which family was chosen for the ﬁrst option, since only protocols of that

family can be chosen as protocol. So with our usual AF_INET option selected we can only use IP-based

protocols [8].

Also it should already be noted here that the IPPROTO_RAW constant in for most operating system (depends

on the Linux/Unix distribution) does imply that the socket also expects an IP header to be manually created

by the user [8]. If we chose this constant we have layer 3 write access as a result. The regular way to do

this is to use another constant and then to change the socket options with setsockopt() as described in

section 3.2.3 on the next page.

In addition to these constants we could also use constants that are deﬁned for layer 2 (PACKET-sockets) to

access their protocol information. These constants are operating system dependent and therefore code that uses

them cannot be ported as easy as the general constants from the previous table. As an example, table 48 in the

appendix shows the constants in Linux for Ethernet protocols which are deﬁned in the <linux/if_ether.h>

header.

Unix The socket() function is POSIX and 4.4BSD conform [8]. The SOCK_NONBLOCK and SOCK_CLOEXEC

ﬂags are Linux-speciﬁc [8]. The function is generally portable to BSD systems, but some systems require the

<sys/types.h> header to work [8]. The manifest constants might also be diﬀerent under some BSD versions.

3.2.2 setsockopt()

The setsockopt() function like the name implies can be used to change the options that are selected for the

socket. The function can manipulate the options for diﬀerent protocol levels such as IP or TCP, but also for the

sockets level API by setting the level to SOL_socket. The function which is deﬁned in the <sys/socket.h>

header has the following form [8]:

int setsockopt(int sockfd, int level, int optname, const void

optval, socklen_t

optlen)

The following parameter can be set [8]:

• sockfd - Speciﬁes the socket for which the options should be set.

• level - The protocol level of the option we want to set.

• optname - The name of the option we want to set. Together with the optval and optlen it is passed

uninterpreted to the protocol module for processing.

• optval - The buﬀer for the option we want to specify, usually an Integer. It should then be non-zero to enable

a Boolean option and zero to disable it.

• optlen - The length of the buﬀer that optval points to in bytes.

We want to only give an short overview over the most interesting options for us, the socket level and the IP

protocol level, which can be set with the setsockfunction() function. Additional information about the use

and meaning of the options can be found in the programmer manuals for the protocols. They exist for all protocols

available for the respective operating system or distribution.

For the socket level API that can be accessed with SOL_socket as the level, the options in table 49 in the

appendix are supported and already included in the <sys/socket.h> header.

For the IP level API that can be accessed with IPPROTO_IP as the level, table 50 in this appendix shows the

following options supported and already included in the <netinet/ip.h> header.

The function returns zero on success and -1 on an error [8]. Additionally the variable errno deﬁned in

<errno.h> is set and can have the following values:

Flag Description

EBADF The argument sockfd is not a valid descriptor.

EFAULT The address pointed to by optval is not in a valid part of the process address space.

EINVAL optlen invalid or invalid optval.

ENOPROTOOPT The option is unknown at the level indicated.

ENOTSOCK The argument sockfd is a ﬁle, not a socket.

Table 6: Errno ﬂags for setsockopt() as deﬁned in <errno.h>

[8]

Unix The function is POSIX and 4.4BSD conform [8]. According to the POSIX-standard the use of setsockopt()

does only require to include <sys/socket.h> header, so under Linux it can be used by only including this single

header [8]. To use it under Unix also require the <sys/types.h> header to be included [8]. For portability it is

generally recommended to include both.

3.2.3 getsockopt()

For retrieving an speciﬁed option of the socket the getsockopt() function deﬁned in the <sys/socket.h> header

can be used [8]:

int getsockopt(int sockfd, int level, int optname, void

optval, socklen_t

optlen)

The following parameter have to be set [8]:

• sockfd - Speciﬁes the socket for which the options should be retrieved.

• level - The protocol level of the option we want to retrieve.

• optname - The name of the option we want to retrieve. Together with the optval and optlen it is passed

uninterpreted to the protocol module for processing.

• optval - The buﬀer for the option we want to retrieve.

• optlen - The length of the buﬀer that optval points to in bytes. Initially it should contain the length of the

buﬀer, after the call it indicates the actual size of the value returned. In case no value is supplied or returned

it might return NULL.

The function returns zero on success and -1 on an error [8]. Additionally the variable errno deﬁned in

<errno.h> is set and can have the following values:

剩余85页未读，继续阅读

csitee84

粉丝: 0
资源: 8

RAW-sockets详解：底层数据传输的透明编程入门

C#.Net开发的LAN井字游戏: XO-Sockets实现指南

UNIX网络编程：卷1 第三版 - Sockets API详解

Unix网络编程卷1：第三版 - Sockets网络API实战指南

Introduction-to-sockets.rar_delphi

raw-sockets:用于Web平台的Raw Sockets API

traceroute-js:使用dgram和raw-sockets的javascript中的traceroute实现

level5-03-sockets-gabrielsong9674：level5-03-sockets-gabrielsong9674由GitHub Classroom创建

InterProcess-Communication-using-sockets

sd-2020-2-sockets

Fluter-Node-Unity-Sockets

最新资源