Sock raw что это
Raw сокеты WinSocket C++
Raw сокеты WinSocket C++. В данной статье – примере мне хотелось бы показать работу с простыми(raw) сокетами. Данные сокеты позволяют получить доступ к базовому протоколу передачи данных, это дает нам большие возможности создания таких сетевых утилит как Ping, Traceroute, а также для организации IP Spoofing, DDoS, ICMP-flood, и многого еще =) Рассматривать будем только протокол IP, так как большинство других протоколов вообще не поддерживают простые сокеты, разве только ATM.
Поддержка данного типа сокетов начинается только в Windows Sockets 2-ой версии. Первое, что необходимо сделать для использования данного типа сокета – это его создание. Для этого запускаем Visual C++, далее создаем новый проект(«CTRL+N» или File->New), тип проекта «Win32 Console Application», и пишем следующий код:
Как видно из приведенного кода, для создания простого сокета достаточно указать вторым аргументом функции socket, протокол SOCK_RAW, но самое интересное представляет третий аргумент, в приведенной выше коде мы использовали IPPROTO_ICMP, но так же можно использовать IPPROTO_IGMP, IPPROTO_IP, IPPROTO_UDP, IPPROTO_RAW, IPPROTO_TCP, все эти параметры позволяют нам манипулировать заголовками представленных протоколов. При самостоятельном заполнение IP заголовка, необходимо добавить в код следующие строки:
Это позволит функции отправки(send, sendto) отправить заголовок IP перед посылаемыми данными, а функция приема вернет этот заголовок вместе с данными. На рисунке представленном ниже показан заголовок IP.
Теперь нам надо определить структуру, которая будет представлять IP заголовок:
Для начальных опытов мы попробуем создать простой UDP сокет, так как он проще, его величина всего 8 байт, содержит 4 поля, более наглядно показано на рисунке ниже. 
Определение структуры UDP заголовка.
Как Вы знаете протокол UDP ненадежный и не гарантирует доставку данных, значит вычисление контрольной суммы не обязательно, хотя и можно это сделать. Для этого используется псевдозаголовок представленный на рисунке: 
Контрольная сумма UDP рассчитывается точно так же, как контрольная сумма IP заголовка, сумма 16-битных слов с переполнением. Если UDP датаграмма состоит из нечетного количества байт то необходимо в конце датаграммы добавить нулевые байты заполнения(который не передаются). Для расчета контрольной суммы в коде программы мы будем использовать следующею функцию, которая одинаковая для всех протоколов TCP/IP:
Как работать с сырыми сокетами (SOCK_RAW) | Часть 1
Представляем вашему вниманию гайд по работе с сырыми сокетами (SOCK_RAW). Не пугайтесь, здесь автоперевод. Если есть желание (и знание английского языка), в конце статьи ссылка на первоисточник.
0x1. Вступление
Цель этой статьи — объяснить часто неправильно понимаемую природу сырых сокетов. Движущей силой написания этого текста стало любопытство автора. чтобы изучить все тонкости этого мощного типа сокетов, также известного как SOCK_RAW. То, что здесь будет обсуждаться, * не * будет еще одним руководством о том, как изготовить собственные пакеты вручную. Эта тема много раз обсуждалась чрезмерно и в сети можно найти довольно много упоминаний о нем (микшер и т. д.). Какие Здесь будет обсуждаться то, что необработанные сокеты делают за кулисами.
Мы по этой причине собираюсь углубиться во внутреннее устройство сетевого стека. Предполагается, что читатель уже имеет некоторый опыт работы с сокетами и готов взглянуть на некоторый код ядра, поскольку реализация сырых сокетов фактически зависит от ОС. Мы будет охватывать реализации как FreeBSD 7.0, так и Linux 2.6. Большинство вещей покрыто для FreeBSD может также применяться к OpenBSD, NetBSD и даже MAC OS X.
0x2. Создание
Перво-наперво. Создание. Как создается сырой сокет? Какие основные в хитросплетениях? Необработанный сокет создается путем вызова системного вызова socket (2) и определив тип сокета как SOCK_RAW следующим образом:
где XXX — это * протокол int *, который, как мы обсудим далее, является главный источник путаницы и проблем, вникающий в сам факт того, что здесь могут применяться разные комбинации. Допустимые значения: IPPROTO_RAW, IPPROTO_ICMP, IPPOROTO_IGMP, IPPROTO_TCP, 0 (осторожно — см. Ниже), IPPROTO_UDP и т. Д. При другой комбинации возникает другое поведение. И это поведение критично для того, как ядро взаимодействует с приложение, создающее необработанный сокет.
Прежде чем переходить к конкретным комбинациям для каждой ОС, давайте сначала рассмотрим посмотрите на фактическое значение значения * протокола *. Чтобы все протоколы работали одновременно был использован конкретный общий подход к проектированию. Согласно ему, похожие протоколы сгруппированы в домены. Домен обычно определяется тем, что называется семейством протоколов или семейством адресов (последнее является самым последним практика) и ряд констант используются для различения между ними. В самые распространенные из них:
FreeBSD определяет указанные выше значения (почти такие же) в /usr/src/sys/sys/socket.h Как вы уже догадались, мы займемся Семья AF_INET. Семейство Интернета разбивает свои протоколы на протокол типы, каждый из которых может состоять более чем из одного протокол.
Linux определяет типы протоколов семейства Интернет в /usr/src/linux-2.6.*/include/linux/net.h
Если вы в прошлом занимались программированием сокетов, то вы, вероятно, признать некоторые из вышеперечисленных. Один из них должен быть вторым аргументом вызов socket (AF_INET, …, …). Третий аргумент — это значение IPPROTO_XXX, которое определяет фактический протокол над IP. Это важно понимать значение. Это значение / число — то, что IP-уровень будет записывать в Поле protocol_type в его заголовке для определения протокола верхнего уровня. Это Поле «Протокол», как вы видите в IP-заголовке ниже (RFC 791).
Это одно из самых важных полей, поскольку именно оно будет использоваться уровень IP на стороне получателя, чтобы понять, какой уровень находится над ним (для пример TCP или UDP) дейтаграмма должна быть доставлена.
Linux определяет эти протоколы в /usr/src/linux-2.6.*/include/linux/in.h
С таким количеством различных комбинаций лучше всего обсуждать вещи последовательно, чтобы начнем с часто используемого значения протокола * 0 *. Вы когда-нибудь задумывались, как Системный вызов socket (2) волшебным образом находит, какой протокол использовать, даже если он был называется как socket (…, …, 0)? Например, когда приложение вызывает его так:
как ядро узнает, с каким протоколом связать сокет? Дело в том, что ядро не делает никаких предположений — ядро не играет в кости с пользовательским пространством (цитируя сумасшедшего физика и великого ума http://www.quotedb.com/quotes/878 в несколько ином контексте) — в большинстве случаи, которые есть (см. шифрование и энтропию для противоположной парадигмы)
Во FreeBSD все, что он делает, это ассоциирует первый протокол, найденный в связанный список доменов через функцию pffindproto (dom, type).
Давайте будем более конкретными и посмотрим код POC:
Сокет создается с помощью функции ядра socreate (), которая определяется как это: (исходный код из FreeBSD 7.0 /usr/src/sys/kern/uipc_socket.c)
Секрет кроется в двух функциях pffindproto () и pffindtype (). Если proto == 0, тогда вызывается pffindtype, который менее строг, чем pffindproto (). Как видно из кода, pffindtype () не проверяет значение протокола в all и просто возвращает * первую * структуру protosw, которую он находит, выводя ее из только pr_type (тип протокола: SOCK_STREAM, SOCK_DGRAM, SOCK_RAW и т. д.) и семья / домен (AF_INET, AF_LOCAL и т. д.).
Каждая структура protosw (переключение протокола) представляет собой ассоциацию типа SOCK_XXX и Протокол IPPROTO_XXX. Все структуры protosw находятся внутри таблицы inetsw [] на который указывает запись inetdomain в связанном списке глобальных доменов. Графическое представление может немного прояснить ситуацию: домены:
Примечание. Место IP (raw) в 4-м индексе (inetsw [3]) упоминается для исторические причины и более новые реализации стека FreeBSD отличаются в этом отношении. В частности, если в ядре определена поддержка SCTP, тогда IP (необработанный), ICMP и остальные перемещаются на 3 позиции вверх по массиву inetsw [] фактически становится inetsw [6], inetsw [7] и т. д. Конечно, здесь нет никаких значительная разница в исходных кодах ядра, поскольку inetsw [] никогда не используется индекс, но по имени. На протяжении всего текста мы будем использовать соглашение, относящееся к записи по умолчанию (inetsw [3]) как default_RAW и запись RAW с подстановочными знаками (последний член inetsw [] и в старые времена inetsw [6]) как wildcard_RAW для ясности.
Вернемся к поиску, который выглядит так:
pffindtype:
обе функции возвращают запись inetsw [] (то есть указатель protosw * на соответствующее смещение массива) /usr/src/sys/kernel/uipc_domain.c:
Изучая приведенный выше код, мы замечаем еще одно важное значение SOCK_RAW. По сути, последние несколько строк pffindproto () используют SOCK_RAW как резервный протокол по умолчанию. Это означает, что если пользовательское приложение вызывает socket (2) вот так: сокет
То же самое и с таким вызовом:
Тип SOCK_RAW и IPPROTO_TCP не совпадают, поскольку SOCK_RAW имеет только записи для ICMP, IGMP и сырого IP. Однако это идеальный правильный вызов, поскольку ядро вернет подстановочный знак SOCK_RAW.
Это касается FreeBSD. Что касается Linux, возможно, у вас уже есть видно из фрагмента кода сверху (in.h), значение * 0 * на самом деле определяется как другой тип протокола для TCP. Эта практика имеет сильный эффект в переносе приложений между * BSD и Linux. Например, для * BSD это верный:
Обратите внимание, что при вводе значения 0 будет возвращена запись default_RAW, а не запись с подстановочным знаком, так как pffindtype () вернет первую структуру protosw с тип SOCK_RAW внутри таблицы inetsw [] и первый — default_RAW Вход.
В Linux вы получите ошибку EPROTONOSUPPORT. См. Код ядра ниже, чтобы понять, почему это происходит.
Случай 8 демонстрирует, как Linux использует SOCK_RAW в качестве резервного протокола, как и мы видели выше с FreeBSD.
Это не единственные различия между двумя системами. Мы обсудим больше из них дальше.
TCP/IP Raw Sockets
A raw socket is a type of socket that allows access to the underlying transport provider. This topic focuses only on raw sockets and the IPv4 and IPv6 protocols. This is because most other protocols with the exception of ATM do not support raw sockets. To use raw sockets, an application needs to have detailed information on the underlying protocol being used.
Winsock service providers for the IP protocol may support a socket type of SOCK_RAW. The Windows Sockets 2 provider for TCP/IP included on Windows supports this SOCK_RAW socket type.
There are two basic types of such raw sockets:
Determining if Raw Sockets are Supported
If a Winsock service provider supports SOCK_RAW sockets for the AF_INET or AF_INET6 address families, the socket type of SOCK_RAW should be included in the WSAPROTOCOL_INFO structure returned by WSAEnumProtocols function for one or more of the available transport providers.
The iAddressFamily member in the WSAPROTOCOL_INFO structure should specify AF_INET or AF_INET6 and the iSocketType member of the WSAPROTOCOL_INFO structure should specify SOCK_RAW for one of the transport providers.
The iProtocol member of the WSAPROTOCOL_INFO structure may be set to IPROTO_IP. The iProtocol member of the WSAPROTOCOL_INFO structure may also be set to zero if the service provider allows an application to use a SOCK_RAW socket type for other network protocols other than the Internet Protocol for the address family.
The other members in the WSAPROTOCOL_INFO structure indicate other properties of the protocol support for SOCK_RAW and indicate how a socket of SOCK_RAW should be treated. These other members of the WSAPROTOCOL_INFO for SOCK_RAW normally specify that the protocol is connectionless, message-oriented, supports broadcast/multicast (the XP1_CONNECTIONLESS, XP1_MESSAGE_ORIENTED, XP1_SUPPORT_BROADCAST, and XP1_SUPPORT_MULTIPOINT bits are set in the dwServiceFlags1 member), and can have a maximum message size of 65,467 bytes.
On WindowsВ XP and later, the NetSh.exe command can be used to determine if raw sockets are supported. The following command run from a CMD window will display data from the Winsock catalog on the console:
netsh winsock show catalog
The output will include a list that contains some of the data from the WSAPROTOCOL_INFO structures supported on the local computer. Search for the term RAW/IP or RAW/IPv6 in the Description field to find those protocols that support raw sockets.
Creating a Raw Socket
To create a socket of type SOCK_RAW, call the socket or WSASocket function with the af parameter (address family) set to AF_INET or AF_INET6, the type parameter set to SOCK_RAW, and the protocol parameter set to the protocol number required. The protocol parameter becomes the protocol value in the IP header (SCTP is 132, for example).
An application may not specify zero (0) as the protocol parameter for the socket, WSASocket, and WSPSocket functions if the type parameter is set to SOCK_RAW.
Raw sockets offer the capability to manipulate the underlying transport, so they can be used for malicious purposes that pose a security threat. Therefore, only members of the Administrators group can create sockets of type SOCK_RAW on WindowsВ 2000 and later.
Send and Receive Operations
Once an application creates a socket of type SOCK_RAW, this socket may be used to send and receive data. All packets sent or received on a socket of type SOCK_RAW are treated as datagrams on an unconnected socket.
The following rules apply to the operations over SOCK_RAW sockets:
The sendto or WSASendTo function is normally used to send data on a socket of type SOCK_RAW. The destination address can be any valid address in the socket’s address family, including a broadcast or multicast address. To send to a broadcast address, an application must have used setsockopt with SO_BROADCAST enabled. Otherwise, sendto or WSASendTo will fail with the error code WSAEACCES. For IP, an application can send to any multicast address (without becoming a group member).
When sending IPv4 data, an application has a choice on whether to specify the IPv4 header at the front of the outgoing datagram for the packet. If the IP_HDRINCL socket option is set to true for an IPv4 socket (address family of AF_INET), the application must supply the IPv4 header in the outgoing data for send operations. If this socket option is false (the default setting), then the IPv4 header should not be in included the outgoing data for send operations.
When sending IPv6 data, an application has a choice on whether to specify the IPv6 header at the front of the outgoing datagram for the packet. If the IPV6_HDRINCL socket option is set to true for an IPv6 socket (address family of AF_INET6), the application must supply the IPv6 header in the outgoing data for send operations. The default setting for this option is false. If this socket option is false (the default setting), then the IPv6 header should not be included in the outgoing data for send operations. For IPv6, there should be no need to include the IPv6 header. If information is available using socket functions, then the IPv6 header should not be included to avoid compatibility problems in the future. These issues are discussed in RFC 3542 published by the IETF. Using the IPV6_HDRINCL socket option is not recommended and may be deprecated in future.
The recvfrom or WSARecvFrom function is normally used to receive data on a socket of type SOCK_RAW. Both of these functions have an option to return the source IP address where the packet was sent from. The received data is a datagram from an unconnected socket.
For IPv4 (address family of AF_INET), an application receives the IP header at the front of each received datagram regardless of the IP_HDRINCL socket option.
For IPv6 (address family of AF_INET6), an application receives everything after the last IPv6 header in each received datagram regardless of the IPV6_HDRINCL socket option. The application does not receive any IPv6 headers using a raw socket.
Received datagrams are copied into all SOCK_RAW sockets that satisfy the following conditions:
It is important to understand that some sockets of type SOCK_RAW may receive many unexpected datagrams. For example, a PING program may create a socket of type SOCK_RAW to send ICMP echo requests and receive responses. While the application is expecting ICMP echo responses, all other ICMP messages (such as ICMP HOST_UNREACHABLE) may also be delivered to this application. Moreover, if several SOCK_RAW sockets are open on a computer at the same time, the same datagrams may be delivered to all the open sockets. An application must have a mechanism to recognize the datagrams of interest and to ignore all others. For a PING program, such a mechanism might include inspecting the received IP header for unique identifiers in the ICMP header (the application’s process ID, for example).
To use a socket of type SOCK_RAW requires administrative privileges. Users running Winsock applications that use raw sockets must be a member of the Administrators group on the local computer, otherwise raw socket calls will fail with an error code of WSAEACCES. On WindowsВ Vista and later, access for raw sockets is enforced at socket creation. In earlier versions of Windows, access for raw sockets is enforced during other socket operations.
Common Uses of Raw Sockets
One common use of raw sockets are troubleshooting applications that need to examine IP packets and headers in detail. For example, a raw socket can be used with the SIO_RCVALL IOCTL to enable a socket to receive all IPv4 or IPv6 packets passing through a network interface. For more information, see the SIO_RCVALL reference.
Limitations on Raw Sockets
On WindowsВ 7, WindowsВ Vista, WindowsВ XP with Service PackВ 2 (SP2), and WindowsВ XP with Service PackВ 3 (SP3), the ability to send traffic over raw sockets has been restricted in several ways:
TCP data cannot be sent over raw sockets.
UDP datagrams with an invalid source address cannot be sent over raw sockets. The IP source address for any outgoing UDP datagram must exist on a network interface or the datagram is dropped. This change was made to limit the ability of malicious code to create distributed denial-of-service attacks and limits the ability to send spoofed packets (TCP/IP packets with a forged source IP address).
A call to the bind function with a raw socket for the IPPROTO_TCP protocol is not allowed.
The bind function with a raw socket is allowed for other protocols (IPPROTO_IP, IPPROTO_UDP, or IPPROTO_SCTP, for example).
The Microsoft implementation of TCP/IP on Windows is capable of opening a raw UDP or TCP socket based on the above restrictions. Other Winsock providers may not support the use of raw sockets.
There are further limitations for applications that use a socket of type SOCK_RAW. For example, all applications listening for a specific protocol will receive all packets received for this protocol. This may not be what is desired for multiple applications using a protocol. This is also not suitable for high-performance applications. To get around these issues, it may be required to write a Windows network protocol driver (device driver) for the specific network protocol. On WindowsВ Vista and later, Winsock Kernel (WSK), a new transport-independent kernel mode Network Programming Interface can be used to write a network protocol driver. On Windows ServerВ 2003 and earlier, a Transport Driver Interface (TDI) provider and a Winsock helper DLL can be written to support the network protocol. The network protocol would then be added to the Winsock catalog as a supported protocol. This allows multiple applications to open sockets for this specific protocol and the device driver can keep track of which socket receives specific packets and errors. For information on writing a network protocol provider, see the sections on WSK and TDI in the Windows Driver Kit (WDK).
Applications also need to be aware of the impact that firewall settings may have on sending and receiving packets using raw sockets.
Настоящее sock_raw’вище
Raw сокеты предоставляют программисту более широкие возможности по сравнению с остальной частью сокетного API. Все знают об этих «широких» возможностях, но более или менее систематизированное их описание встречается в Интернете нечасто. Попробуем, восполнить данный пробел и разобраться с предназначением raw cокетов и вариантами их применения в сетевом ПО.
Итак, raw сокеты — особый вид сокетов, доступный при использовании системного вызова типа:
Не удержусь и сделаю небольшое отступление по поводу возможных аргументов в вызове socket и их концептуального значения. Все мы знаем, что сокетный API задумывался как генерализированный интерфейс программирования, т.е. интерфейс, посредством которого можно будет работать с самыми различными механизмами сетевого, а то и просто внутрихостового взаимодействия. Первый аргумент вызова выбирает т.н. коммуникационный домен. Создатели сокетного API отвели под межсетевое взаимодействие на базе TCP/IP (IPv4) коммуникационный домен AF_INET, который мы и указываем в нашем вызове. Второй аргумент задает тип сокета — сокеты типизируются в соответствии с семантикой передачи данных, которую они обеспечивают (SOCK_STREAM — потоковая передача, SOCK_DGRAM — дейтаграммная передача). В нашем случае используется тип сокета SOCK_RAW — наверное это единственное отступление от правил, когда второй аргумент означает не столько семантику передачи, сколько доступ к специальному низкоуровневому функционалу. Наконец, третий аргумент задает протокол. Список констант, большинство из которых можно использовать в качестве третьего аргумента в нашем вызове, можно посмотреть в файле /usr/src/linux-*/include/linux/in.h, где * — версия ядра. Наиболее часто используются константы IPPROTO_TCP, IPPROTO_UDP, IPPROTO_ICMP, IPPOROTO_IGMP, IPPROTO_RAW.
Когда начинаешь работать с raw сокетами, сразу замечаешь, по крайней мере, две их особенности — то как осуществляется инкапсуляция данных и наличие доступа к IP-заголовкам. Посылаемые с помощью raw сокета данные инкапсулируются непосредственно в поле полезной нагрузки IP-дейтаграммы, минуя транспортный уровень. Что касается заголовков, то тут удобно выделить две ситуации – отправка и прием дейтаграммы. Пользовательское приложение, использующее raw сокеты, всегда получает IP-дейтаграмму целиком, включая её заголовок. При этом все необходимые проверки валидности полей заголовка дейтаграммы все равно осуществляются ядром, и приложение никогда не получит через raw сокет дейтаграмму, в которой указана, к примеру, невалидная версия протокола IP (т.е. версия отличная от IPv4).
При отправке данных через raw сокет у программиста есть выбор – переложить задачу создания IP заголовков на ядро или создавать заголовки самому. Второе возможно при использовании сокетной опции IP_HDRINCL (плюс в Linux есть ситуация, когда данная опция будет включена автоматически, если в качестве третьего аргумента в вызове socket() использовать константу IPPROTO_RAW). Однако, даже в случае использования опции IP_HDRINCL ядро все равно будет “ассистировать” программисту. Так, поля заголовка дейтаграммы Total Length и Header Checksum всегда автоматически заполняются ядром, а поля Source Address и Identification будут заполнены ядром, если программист оставит их значения равными нулю. Возможность создать свой заголовок дейтаграммы используется в основном для отправки пакетов с «проспуфленным» source IP-адресом.
Raw сокеты могут использоваться как несколько ограниченный в своих возможностях механизм packet capture. Ограничен он по ряду причин. Во-первых, через raw сокет можно получать только копию входящего пакета, но не генерируемого данной машиной и не транзитируемого (маршрутизируемого). Во-вторых, через raw сокет можно получать только IP-дейтаграммы с заданным Protocol ID (Protocol ID соответствует третьему аргументу в системном вызове socket(), использовавшимся при создании сокета), а не весь IP-трафик. Наконец, отличительной особенностью raw сокетов во FreeBSD (но не Linux) является то, что мы сможем получить IP-дейтаграмму, только если ядро не знает как ее обрабатывать (исключение — пакеты протоколов ICMP и IGMP, о которых скажем ниже). Здесь имеется ввиду, что в ядре не реализован код, предназначенный для обработки IP-дейтаграммы с указанным в ней Protocol ID. Также, интересен следующий факт — если создано более одного raw сокета с аналогичными параметрами, каждый сокет будет получать по собственной копии входящего пакета.
Raw сокеты незаменимы при написании сетевых сканеров. К примеру, мы можем использовать вызов типа:
Далее нам остается только сконструировать TCP-сегмент и передать его на отправку raw сокету. Не забываем так же и о возможности подделки source IP-адреса, которая в данном контексте придется очень кстати. Аналогичным образом, можно писать программы для фаззинга сетевого стека ядра. К примеру, конструируемые пакеты транспортного уровня могут содержать заведомо невалидные значения в нужных нам полях.
При использовании протокола TCP через raw сокет стоит понимать следующую вещь. Мы не можем полностью воссоздать работу протокола TCP, да у нас это и не получится, исходя из возможностей, предоставляемых raw сокетами. Максимум, что мы сможем сделать — это принимать входящий трафик этого типа (в Linux) и отправлять отдельно взятые исходящие TCP-сегменты, якобы являющиеся частью установленного или устанавливаемого TCP-соединения.
Наконец, стоит упомянуть еще один аспект использования raw сокетов. Существуют протоколы, работа которых контролируется, главным образом, самим ядром, например ICMP и IGMP. В ряде случаев, доступ к этим протоколам из пользовательского приложения может быть весьма полезен:
Именно так написаны такие утилиты как ping, классический tracert (ICMP), а также утилиты, позволяющие манипулировать подпиской по IGMP.
Таким образом, собрав воедино все факты, можно попытаться сделать вывод о предназначении raw сокетов. Данный механизм пригодится нам, если нужно реализовать:
Сложно себе представить, что функционал, предоставляемый raw сокетами, был изначально призван поощрить написание софта для проведения сетевых атак. Скорее обоснованием необходимости данного механизма послужили достаточно мирные цели. Однако возможности raw сокетов, в конечном счете, нашли применение и в хакерском софте.
Ссылки на полезные ресурсы по теме