Статья отвечает на вопрос насколько опасно блокировать ICMP трафик.
Многие сетевые администраторы считают, что протокол межсетевых управляющих сообщений (Internet Control Message Protocol (ICMP) представляет собой угрозу безопасности и поэтому должен всегда блокироваться на . Это правда, что протокол имеет некоторые связанные с этим проблемы безопасности, и что часть запросов должна быть заблокирована. Но это не повод блокировать весь ICMP-трафик!
ICMP-трафик имеет много важных функций; какие то из них полезны для устранения неполадок, другие же необходимы для правильной работы сети. Ниже приведены сведения о некоторых важных составляющих ICMP протокола, о которых вы должны знать. Следует подумать над тем, как оптимальным образом пропускать их через вашу сеть.
Echo запрос и and Echo ответ
IPv4 – Echo запрос (Type8, Code0) и Echo ответ (Type0, Code0)
IPv6 – Echo запрос (Type128, Code0) and Echo ответ (Type129, Code0)
Мы все хорошо знаем, что ping, - один из первых инструментов для поиска и устранения неполадок. Да, если вы включите на своем оборудование обработку ICMP-пакетов, то это значит, что ваш хост теперь доступен для обнаружения, но разве ваш уже не слушает порт 80, и не отправляет ответы на клиентские запросы? Конечно, заблокируйте ещё и эти запросы, если вы действительно хотите, чтобы на границе сети была ваша DMZ. Но блокируя ICMP трафик внутри вашей сети, не усилите защиту, напротив получите систему с излишне сложным процессом поиска и устранения неполадок («Проверьте пожалуйста отзывается ли шлюз на сетевые запросы?», «Нет, но это меня ничуть не расстраивает, потому что мне это ничего не скажет! »).
Помните, также можете разрешить прохождение запросов в определенном направлении; например, настроить оборудование так, чтобы Echo запросы из вашей сети проходили в сеть Интернет и Echo ответы из Интернета в вашу сеть, но не наоборот.
Необходима фрагментация пакета (IPv4) / Пакет слишком большой (IPv6)
IPv4 – (Type3, Code4)
IPv6 – (Type2, Code0)
Данные компоненты протокола ICMP очень важны, так как являются важным компонентом в Path MTU Discovery (PMTUD), который является неотъемлемой частью протокола TCP. Позволяет двум хостам корректировать значение максимального размера сегмента TCP (MSS) до значения, которое будет соответствовать наименьшему MTU по пути связей между двумя адресатами. Если на пути следования пакетов будет узел с меньшим Maximum Transmission Unit, чем у отправителя или получателя, и у них не будет средств для обнаружения данной коллизии, то трафик будет незаметно отбрасывается. И вы не будете понимать что происходит с каналом связи; другими словами, «для вас наступят веселые деньки».
Don’t Fragment – ICMP не пройдет!
Передача IPv4-пакетов с установленным битом Don’t Fragment (большинство из них!) или IPv6-пакетов (помним, что в IPv6 нет фрагментации маршрутизаторами), которые слишком велики для передачи через интерфейс, приведёт к тому, что маршрутизатор отбросит пакет и сформирует ответ источнику передачи с следующими ICMP-ошибками: Требуется Фрагментация (Fragmentation Required ), либо Пакет Слишком Большой (Packet Too Big). Если ответы с этими ошибками не смогут вернуться к отправителю, то он будет интерпретировать отсутствие подтверждающих ответов о доставке пакетов ACK (Acknowledge ) от получателя в качестве перегрузки / потери и источником для повторной передачи пакетов, которые также будут отбрасываться.
Сложно выявить причину подобной проблемы и быстро устранить, процесс обмена TCP-рукопожатиями (TCP-handshake) работает нормально, поскольку в нем задействованы небольшие пакеты, но как только происходит массовая передача данных сеанс передачи зависает, так как источник передачи не получает сообщения об ошибках.
Исследование пути доставки пакетов
RFC 4821 был разработан для того, чтобы помочь участникам передачи трафика в сети обойти эту проблему, используя исследование пути распространения пакетов (Path MTU Discovery (PLPMTUD) . Стандарт позволяет обнаружить максимальный объём данных (Maximum Transmission Unit (MTU) , который может быть передан протоколом за одну итерацию, путем постепенного увеличения максимального размера полезного блока данных (Maximum Segment Size (MSS) , для того чтобы найти максимально возможную величину пакета без его фрагментации на пути следования от передатчика к приемнику. Данный функционал уменьшает зависимость от своевременного получения ответов с ошибками по протоколу межсетевых управляющих сообщений (Internet Control Message Protocol (ICMP) и доступен в большинстве сетевых стеков устройств и клиентских операционных систем. К сожалению, он не так эффективен, как непосредственное получение данных о максимальном возможном размере передаваемых пакетов. Пожалуйста, позвольте этим сообщениям протокола ICMP возвращаться к источнику передачи, хорошо?
Превышение времени передачи пакетов
IPv4 – (Type11, Code0)
IPv6 – (Type3, Code0)
Traceroute - очень полезный инструмент для устранения неполадок в сетевых соединениях между двумя хостами, подробно описывающий каждый шаг пути.
Отправляет пакет с временем жизни пакета данных для протокола IP (Time to live (TTL) равным 1 , чтобы первый маршрутизатор отправил сообщение с ошибкой (включая собственный IP-адрес) о превышении времени жизни пакета. Затем отправляет пакет с TTL 2 и так далее. Данная процедура необходима для того, чтобы обнаружить каждый узел на пути следования пакетов.
NDP and SLAAC (IPv6)
Router Solicitation (RS) (Type133, Code0)
Router Advertisement (RA) (Type134, Code0)
Neighbour Solicitation (NS) (Type135, Code0)
Neighbour Advertisement (NA) (Type136, Code0)
Redirect (Type137, Code0)
В то время как IPv4 использовал протокол разрешения адресов (ARP) для сопоставления 2 и 3 уровней сетевой модели OSI, IPv6 использует другой подход в виде протокола обнаружения соседей (NDP). NDP предоставляет множество функций, включая обнаружение маршрутизатора, обнаружение префикса, разрешение адреса и многое другое. В дополнение к NDP, Автоконфигурация (StateLess Address AutoConfiguration (SLAAC) позволяет динамически настраивать хост в сети, аналогично концепции протокола динамической настройки узла (Dynamic Host Configuration Protocol (DHCP) (хотя DHCPv6 предназначается для более тонкого управления).
Эти пять типов ICMP сообщений не должны блокироваться внутри вашей сети (не учитываем внешний периметр), чтобы протокол передачи данных IP функционировал правильно.
Нумерация типов ICMP
Протокол межсетевых управляющих сообщений (ICMP) содержит много сообщений, которые идентифицируются полем «тип».
| Тип | Наименование | Спецификация |
|---|---|---|
| Echo Reply | ||
| 1 | Unassigned | |
| 2 | Unassigned | |
| 3 | Destination Unreachable | |
| 4 | Source Quench (Deprecated) | |
| 5 | Redirect | |
| 6 | Alternate Host Address (Deprecated) | |
| 7 | Unassigned | |
| 8 | Echo | |
| 9 | Router Advertisement | |
| 10 | Router Solicitation | |
| 11 | Time Exceeded | |
| 12 | Parameter Problem | |
| 13 | Timestamp | |
| 14 | Timestamp Reply | |
| 15 | Information Request (Deprecated) | |
| 16 | Information Reply (Deprecated) | |
| 17 | Address Mask Request (Deprecated) | |
| 18 | Address Mask Reply (Deprecated) | |
| 19 | Reserved (for Security) | Solo |
| 20-29 | Reserved (for Robustness Experiment) | ZSu |
| 30 | Traceroute (Deprecated) | |
| 31 | Datagram Conversion Error (Deprecated) | |
| 32 | Mobile Host Redirect (Deprecated) | David_Johnson |
| 33 | IPv6 Where-Are-You (Deprecated) | |
| 34 | IPv6 I-Am-Here (Deprecated) | |
| 35 | Mobile Registration Request (Deprecated) | |
| 36 | Mobile Registration Reply (Deprecated) | |
| 37 | Domain Name Request (Deprecated) | |
| 38 | Domain Name Reply (Deprecated) | |
| 39 | SKIP (Deprecated) | |
| 40 | Photuris | |
| 41 | ICMP messages utilized by experimental mobility protocols such as Seamoby | |
| 42 | Extended Echo Request | |
| 43 | Extended Echo Reply | |
| 44-252 | Unassigned | |
| 253 | RFC3692-style Experiment 1 | |
| 254 | RFC3692-style Experiment 2 | |
| 255 | Reserved |
Пара слов об ограничении скорости
Хотя ICMP-сообщения, подобные тем, которые описаны в статье, могут быть очень полезными, помните, что генерация всех этих сообщений занимает процессорное время на ваших маршрутизаторах и генерирует трафик. Вы действительно ожидаете, что вы получите 1000 пингов в секунду через ваш брандмауэр в обычной ситуации? Будет ли это считаться нормальным трафиком? Вероятно, нет. Ограничивайте пропускную способность сети для этих типов ICMP трафика, как вы считаете нужным; этот шаг может помочь вам в защите вашей сети.
Основные понятия, стандарты и организации, действующие в области ИС.
Взаимодействие открытых систем(Open Systems Interconnection (OSI ))
Взаимодействие открытых систем - правила сопряжения систем с открытой архитектурой от различных производителей.
Архитектура безопасности(Security architecture)
Архитектура безопасности - официальное дополнение ISO к модели OSI, определяющее меры безопасности в информационной сети.
Архитектура безопасности предполагает:
Предотвращение чтения сообщений любыми лицами;
Защиту трафика от его анализа посторонними;
Обнаружение изменений потоков сообщений;
Определение искажений блоков данных.
В зависимости от используемых методов различают:
Сети со слабой защитой, в которых усилия нарушителя пропорциональны затратам отправителя;
Сети с сильной защитой, требующие резкого увеличения затрат нарушителя.
Базовая эталонная модель взаимодействия открытых систем (Модель OSI)
(Стандарт ISO 7498 (Open systems interconnection basic reference model))
Базовая эталонная модель взаимодействия открытых систем - стандарт ISO, определяющий процесс информационного взаимодействия двух или более систем, в виде совокупность информационных взаимодействий уровневых подсистем.
Система обработки сообщений (Message Handling System (MHS ))
Система обработки сообщений - в модели OSI - система агентов сообщений пользователя, агентов передачи сообщений, хранения сообщений и устройств доступа, обеспечивающая работу электронной почты.
Уровень (Layer)
Уровень - в модели OSI - набор структур и программ, обеспечивающих обработку определенного класса событий.
Уровень выступает единицей декомпозиции совокупности функций, обеспечивающих информационное взаимодействие прикладных процессов.
В модели OSI выделяют семь уровней информационного взаимодействия:
7- прикладной уровень: передача информации между программами;
6- уровень представления: шифрование, кодирование и сжатие данных;
5- сеансовый уровень: установка, поддержка и разрыв соединения;
4- транспортный уровень: точность доставки, уровень качества услуг;
3- сетевой уровень: маршруты передачи, обработка и передача сообщений;
2- канальный уровень: управление каналом связи, доступ к среде передачи и адресация;
1- физический уровень: cвязь на уровне аппаратуры.
Уровни не зависят друг от друга и состоят из активных объектов, которые:
Взаимодействуют с другими объектами того же уровня;
Предоставляют сервис смежному с ним верхнему уровню;
Получают сервис от смежного с ним нижнего уровня;
Обмениваются блоками данных с целью выполнения возложенных на них задач.
Семиуровневая модель ВОС.
Модель Взаимодействия Открытых Систем (OSI).
Эталонная модель OSI, иногда называемая стеком OSI представляет собой 7-уровневую сетевую иерархию, разработанную Международной организацией по стандартам (International Standardization Organization - ISO). Эта модель содержит в себе по сути 2 различных модели:
Горизонтальную модель на базе протоколов, обеспечивающую механизм взаимодействия программ и процессов на различных машинах
Вертикальную модель на основе услуг, обеспечиваемых соседними уровнями друг другу на одной машине
В горизонтальной модели двум программам требуется общий протокол для обмена данными. В вертикальной - соседние уровни обмениваются данными с использованием интерфейсов API.
Уровень 7, прикладной
Прикладной уровень отвечает за доступ приложений в сеть. Задачами этого уровня является перенос файлов, обмен почтовыми сообщениями и управление сетью. (FTP, Telnet,…)
Уровень 6, представления
Этот уровень обеспечивает преобразование данных (кодирование, компрессия и т.п.). Обеспечивает независимость прикладных процессов от различных форм представления данных.
Уровень 5, сеансовый
Обеспечивает механизм организации и формирования структуры взаимодействия между прикладными процессами.
Уровень 4, транспортный
Транспортный уровень делит потоки информации на достаточно малые фрагменты (пакеты) для передачи их на сетевой уровень. В стеке TCP/IP происзодит контроль целостности передачи данных. (TCP).
Уровень 3, сетевой
На этом уровне происходит маршрутизация пакетов на основе преобразования MAC-адресов в сетевые адреса. Сетевой уровень обеспечивает также прозрачную передачу пакетов на транспортный уровень. (IP).
Уровень 2, канальный
Канальный уровень обеспечивает создание, передачу и прием кадров данных. Этот уровень обслуживает запросы сетевого уровня и использует сервис физического уровня для приема и передачи пакетов. Спецификации IEEE 802.x делят канальный уровень на два подуровня: управление логическим каналом (LLC) и управление доступом к среде (MAC). LLC обеспечивает обслуживание сетевого уровня, а подуровень MAC регулирует доступ к разделяемой физической среде. (Ethernet).
Уровень 1, физический
Физический уровень получает пакеты данных от вышележащего канального уровня и преобразует их в оптические или электрические сигналы, соответствующие 0 и 1 бинарного потока. Эти сигналы посылаются через среду передачи на приемный узел. Механические и электрические/оптические свойства среды передачи определяются на физическом уровне и включают:
· Тип кабелей и разъемов
· Разводку контактов в разъемах
· Схему кодирования сигналов для значений 0 и 1
На сетевом уровне формируется IP-пакет: DATA|IP-заголовок
На канальном уровне формируется кадр: DATA|IP-заголовок|Ethernet-заголовок:
· 1 IP-паке в один кадр
· 1 IP-пакет разбивается на несколько кадров
· Несколько IP-пакетов помещаются в 1 кадр
3. TCP/IP, распределение протоколов по уровням ВОС.
Transmission Control Protocol/Internet Protocol (TCP/IP) - это промышленный стандарт стека протоколов, разработанный для глобальных сетей.
Стандарты TCP/IP опубликованы в серии документов, названных Request for Comment (RFC). Документы RFC описывают внутреннюю работу сети Internet. Некоторые RFC описывают сетевые сервисы или протоколы и их реализацию, в то время как другие обобщают условия применения.
Так как стек TCP/IP был разработан до появления модели взаимодействия открытых систем ISO/OSI, то, хотя он также имеет многоуровневую структуру, соответствие уровней стека TCP/IP уровням модели OSI достаточно условно.
Структура протоколов TCP/IP приведена на рисунке 2.1. Протоколы TCP/IP делятся на 4 уровня.
Рис. 2.1. Стек TCP/IP
(уровень IV ) соответствует физическому и канальному уровням модели OSI. Этот уровень в протоколах TCP/IP не регламентируется, но поддерживает все популярные стандарты физического и канального уровня: Ethernet, Token Ring, FDDI, Fast Ethernet, PPP и т.д..
(уровень III ) - уровень межсетевого взаимодействия, который занимается передачей пакетов с использованием различных транспортных технологий локальных сетей, территориальных сетей, линий специальной связи и т. п. В качестве основного протокола сетевого уровня (в терминах модели OSI) в стеке используется протокол IP . Протокол IP является дейтаграммным протоколом, то есть он не гарантирует доставку пакетов до узла назначения. Также протоколы RIP, OSPF, ICMP и др.
(уровень II ) называется основным. На этом уровне функционируют протокол управления передачейTCP (Transmission Control Protocol) и протокол дейтаграмм пользователя UDP (User Datagram Protocol). Протокол TCP обеспечивает надежную передачу сообщений между удаленными прикладными процессами за счет образования виртуальных соединений. Протокол UDP обеспечивает передачу прикладных пакетов дейтаграммным способом, как и IP, и выполняет только функции связующего звена между сетевым протоколом и многочисленными прикладными процессами.
(уровень I ) называется прикладным. WWW, Telnet, SMTP и т.д..
Протоколы IP, ARP, RARP.
Основу транспортных средств стека протоколов TCP/IP составляет протокол межсетевого взаимодействия - Internet Protocol (IP). Документ – RFC 791. К основным функциям протокола IP относятся:
· перенос между сетями различных типов адресной информации в унифицированной форме,
· сборка и разборка пакетов при передаче их между сетями с различным максимальным значением длины пакета.
Состав IP-кадра:
· Заголовок 20байт
· внутри заголовка 2 блока по 32бита для IP-адресов источника и назначения
· Поле данных
В большинстве типов локальных и глобальных сетей определяется такое понятие как максимальный размер поля данных кадра или пакета, в которые должен инкапсулировать свой пакет протокол IP. Эту величину обычно называют максимальной единицей транспортировки - Maximum Transfer Unit, MTU. Сети Ethernet имеют значение MTU, равное 1500 байт
ARP (Address Resolution Protocol) протокол служит для установления соответствия между IP и MAC адресом (ARP – когда изв. IP, RARP – когда изв. MAC). MAC-адрес – 48бит, прошит в каждой железке (байта – производитель, ещё 3 байта – уникальный номер железки).
В сетях используется IP-адресация, как более гибкая. IP-адрес не привязан к железу.
С помощью ARP заполняется специальная таблица – ARP-кэш, с динамическими записями.
2 узла – А и Б, А знает IP Б и хочет отправить ему данные:
1) А посылает широковещательный ARP запрос с IP адресом Б
2) Б видит свой IP и посылает широковещательный ответ со своим MACом
3) A получает MAC Б, помещает его в ARP-кэш и формиреут Ethernet-кадр (данные|IP-заголовок(IP-адреса)|Ethernet-заголовок(MAC адреса))
Для дальнейшей передачи ARP-запросы не нужны.
RARP – Reverse ARP. Одно из применений – старт бездисковых станций, не знающих в начальный момент своего IP-адреса.
Протоколы TCP , ICMP , UDP.
Transmission Control Protocol (TCP) (протокол управления передачей) - один из основных сетевых протоколов Интернета, предназначенный для управления передачей данных в сетях и подсетях TCP/IP.
Выполняет функции протокола транспортного уровня модели OSI.
TCP - это транспортный механизм, предоставляющий поток данных, с предварительной установкой соединения, за счёт этого дающий уверенность в достоверности получаемых данных, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета.
Единицей данных протокола TCP является сегмент. Информация, поступающая к протоколу TCP в рамках логического соединения от протоколов более высокого уровня, рассматривается протоколом TCP как неструктурированный поток байт. Поступающие данные буферизуются средствами TCP. Для передачи на сетевой уровень из буфера "вырезается" некоторая непрерывная часть данных, называемая сегментом.
Соединение в протоколе TCP идентифицируется парой полных адресов обоих взаимодействующих процессов (оконечных точек). Адрес каждой из оконечных точек включает IP-адрес (номер сети и номер компьютера) и номер порта (FTP – 21, HTTP – 80 и т.д.). Одна оконечная точка может участвовать в нескольких соединениях.
Установление соединения выполняется в следующей последовательности:
· При установлении соединения одна из сторон является инициатором. Она посылает запрос к протоколу TCP на открытие порта для передачи (active open).
· После открытия порта протокол TCP на стороне процесса-инициатора посылает запрос процессу, с которым требуется установить соединение.
· Протокол TCP на приемной стороне открывает порт для приема данных (passive open) и возвращает квитанцию, подтверждающую прием запроса.
· Для того чтобы передача могла вестись в обе стороны, протокол на приемной стороне также открывает порт для передачи (active port) и также передает запрос к противоположной стороне.
· Сторона-инициатор открывает порт для приема и возвращает квитанцию. Соединение считается установленным. Далее происходит обмен данными в рамках данного соединения.
Используется квитирование (подтверждение передачи данных)
ICMP (Internet Control Message Protocol - межсетевой протокол управляющих сообщений) - сетевой протокол, входящий в стек протоколов TCP/IP. В основном ICMP используется для передачи сообщений об ошибках и других исключительных ситуациях, возникших при передаче данных, например, запрашиваемая услуга недоступна, или хост, или маршрутизатор не отвечают. Также на ICMP возлагаются некоторые сервисные функции.
Каждое сообщение протокола ICMP передается по сети внутри пакета IP. Пакеты IP с сообщениями ICMP маршрутизируются точно так же, как и любые другие пакеты, без приоритетов, поэтому они также могут теряться. Кроме того, в загруженной сети они могут вызывать дополнительную загрузку маршрутизаторов. Для того, чтобы не вызывать лавины сообщения об ошибках, потери пакетов IP, переносящие сообщения ICMP об ошибках, не могут порождать новые сообщения ICMP.
Существует несколько типов сообщений ICMP. Каждый тип сообщения имеет свой формат, при этом все они начинаются с общих трех полей: 8-битного целого числа, обозначающего тип сообщения (TYPE), 8-битного поля кода (CODE), который конкретизирует назначение сообщения, и 16-битного поля контрольной суммы (CHECKSUM). Кроме того, сообщение ICMP всегда содержит заголовок и первые 64 бита данных пакета IP, который вызвал ошибку.
UDP (User Datagram Protocol - протокол пользовательских датаграмм) - это транспортный протокол для передачи данных в сетях IP без установления соединения. Он является одним из самых простых протоколов транспортного уровня модели OSI. В отличие от TCP, UDP не гарантирует доставку пакета. Это позволяет ему гораздо быстрее и эффективнее доставлять данные для приложений, которым требуется большая пропускная способность линий связи, либо требуется малое время доставки данных.
Бедному Диалапщику посвящается!
Хочешь разобраться в работе пресловутого
протокола ICMP, о котором все так много говорят? Да, понимаю,
читать толстенные книги по протоколам, в которых понятны только предлоги, или еще хуже — красными глазами читать RFC, держа перед собой толстенный англо-русский словарь, так как твои познания в английском заканчиваются фразой:
"Who`s on duty today? I am on duty today.» — кому хочется?! Ты прекрасно знаешь, что самый верный путь к знаниям — это практика.
Когда ты видишь как формируются пакеты, как они отправляются, ты сможешь в дальнейшем понять и более сложные вещи! Но у тебя гигантская проблема — Windows 9x!
К сожалению работать с пакетами на низком уровне
winsock (библиотека предоставляющая интерфейс работы с сокетами) в этих версиях
(9х) не позволит! Есть несколько способов решения этой проблемы: ставь другую ось
(или старшие версии Windows 2000, XP…) или ищи NDIS драйвер и учись его использовать
(можешь, конечно, сам его написать, но если ты его написал, то зачем тебе читать все это). Но никто не запрещал тебе работать с протоколами высокого уровня.
Чтобы спуфить пакеты, например ICMP, нужно хотя бы знать как они выглядят и для чего вообще предназначены. Я предлагаю тебе инструмент, с помощью которого ты сможешь анализировать ICMP пакеты — а это достаточно важно!
Что тебе нужно для создания своего собственного анализатора ICMP пакетов:
компилятор какого-либо языка (реализующего
winsock, все функции описанные ниже практически не меняют своего интерфейса),
пальцы чтобы написать код, мозги чтобы все это понять.
Итак, начнем. Я написал все на С++ (Borland C++ v5.01). Сначала действуем по стандартному плану создания сервера: инициализируем структуру sockaddr_in таким образом:
Sockaddr_in *addr;
addr = new sockaddr_in;
addr->sin_family = AF_INET; // Семейство адресов AF_INET или PF_INET — каму как нравится.
addr->sin_port = htons(0); // Номер порта нам неважен, мы работаем на низком уровне,
// где номера портов не имеют значение.
addr->sin_addr.s_addr = htonl(INADDR_ANY); // Выбираем любой интерфейс(обычно он один)
Затем инициализируем структуру protoent, чтобы winsock знал с каким протоколом мы будем работать:
protoent *protocol;
protocol = getprotobyname(«icmp»);
Создаем дескриптор сокета:
int sock;
sock = socket(AF_INET,SOCK_RAW,protocol->p_proto);
Обрати внимание, что мы работаем не с SOCK_DGRAM, и уж тем более не с SOCK_STREAM, а с SOCK_RAW, так называемые «сырые» сокеты. Затем, как обычно, проверяем на ошибки и идем далее
(если INVALID_SOCKET, то обломись дружок). Биндим наш сокет с
адресом, которой мы определили в указателе addr:
int err;
err = bind(sock,(sockaddr *)addr,sizeof(*addr));
int rc;
char buffer;
while(true)
{
rc = recvfrom(sock,buffer,sizeof(buffer),0,(sockaddr *)addr,&len);
}
Проверяем на ошибки, если rc == -1 тогда ошибка, иначе все круто
и идем дальше (все это делается внутри бесконечного цикла).
Когда мы получили пакет из сети, в структуре addr у нас хранится
адрес того хорька, который послал тебе этот ICMP пакет, только не в привычном для нас виде
(«четыре точки»), а в машинном. Надо привести его к читаемому виду.
Легко!
cout<<«received from: «< Теперь у нас в руках полученный пакет (в массиве buffer). Что с ним делать? Организуем процедуру для вывода содержимого пакета на экран. Я особо не заморачивался по поводу этой процедуры, так что кому не Теперь о некоторых нюансах. Прежде всего как узнать ось по пингу? Конечно, точно ось не определить, но если тебя пингуют стандартными прогами, входящими в пакет ОС Если поле тип содержит 0 или 8, то знай — это ping . Если Если ты все сделаешь, откомпилишь и запустишь, затем С вопросами можете обращаться по адресу , помогу чем смогу! Протокол передачи команд и сообщений об ошибках ( ICMP
- internet control message protocol, RFC-792, - 1256) выполняет различные и не только диагностические функции. При пересылке пакетов промежуточные узлы не информируются о возникших проблемах, поэтому ошибка в маршрутной таблице может восприниматься как неисправность в узле адресата и достоверно диагностироваться не будет. ICMP-протокол сообщает об ошибках в IP-дейтаграммах, но не дает информации об ошибках в самих ICMP-сообщениях. ICMP использует IP, а IP-протокол должен использовать ICMP. В случае ICMP-фрагментации сообщение об ошибке будет выдано только один раз на дейтаграмму, даже если ошибки были в нескольких фрагментах. Подводя итоги, можно сказать, что ICMP
-протокол: ICMP
-сообщения об ошибках никогда не выдаются: Эти правила призваны блокировать потоки дейтаграмм, посылаемые в отклик на мультикастинг- или широковещательные ICMP
-сообщения. Особенности протокола ICMPv6 описаны в документе RFC-2463. В IPv6 на протокол ICMP
возложены функции управления группами ( IGMP
). ICMP
-сообщения имеют свой формат, а схема их вложения аналогична UDP
или TCP
и представлена на рис. 3.1 . Все ICMP
пакеты начинаются с 8-битного поля типа ICMP
и его кода (15 значений).
По
существу, значения полей типа и кода выполняют почти ту же функцию, что и порт
в ТСР и UDP
-протоколах. Код уточняет функцию ICMP
-сообщения. Таблица 3.1 этих кодов приведена ниже (символом * помечены сообщения об ошибках, остальные являются запросами). Процедура "отключение источника" (quench, поле
тип ICMP=4
) позволяет управлять потоками данных в каналах Интернет
. Не справляясь с обработкой дейтаграмм, ЭВМадресат (или транзитное сетевое устройство) может послать запрос
"отключить источник" отправителю, который может сократить темп посылки пакетов, например, вдвое, или вовсе прервать их посылку. Специальной команды, отменяющей прежние запреты, не существует. Если сообщения об отключении прекращаются, источник может возобновить посылку пакетов или увеличить частоту их отправки. Ниже (на рис. 3.2) представлен формат эхозапроса ( ping
) и отклика для протокола ICMP
. Поля идентификатор
(обычно это идентификатор
процесса) и номер по порядку
(увеличивается на 1 при посылке каждого пакета) служат для того, чтобы отправитель мог связать в пары запросы и отклики. Поле
тип
определяет, является ли этот пакет запросом (8) или откликом (0). Поле
контрольная сумма
представляет собой 16-разрядное дополнение
по
модулю 1 контрольной суммы всего ICMP
-сообщения, начиная с поля тип
. Поле
данные служит для записи информации, возвращаемой отправителю. При выполнении процедуры ping
эхозапрос с временной меткой в поле
данные
посылается адресату. Если адресат активен, он принимает IP
-пакет, меняет адрес
отправителя и получателя местами и посылает его обратно. ЭВМ-отправитель, восприняв этот отклик, может сравнить временную метку, записанную им в пакет, с текущим показанием внутренних часов и определить время распространения пакета ( RTT
- round trip time
). Размер поля данные не регламентирован и определяется предельным размером IP
-пакета. Так как в пакете ICMP
нет поля порт
, то при запуске нескольких процессов PING
одновременно может возникнуть проблема с тем, какому из процессов следует передать тот или иной отклик. Для преодоления этой неопределенности следует использовать уникальные значения полей идентификатор
. Время распространения ICMP
-запроса, вообще говоря, не равно времени распространения отклика (ситуация с очередями, например, в маршрутизаторах может быть разной). Это связано не только с возможными изменениями в канале. В общем случае маршруты их движения могут быть различными. Те же запросы используются при выполнении процедуры Traceroute
. Эта процедура позволяет не только диагностировать, но и оптимизировать маршрут
. Например, команда
traceroute cernvm.cern.ch
, выданная в ЭВМ SUN
(ИТЭФ), может отобразить на экране (в скобках указаны IP
-адреса узлов и значения времени жизни дейтаграмм, значения RTT
приводится в миллисекундах) (таблица 3.1.1.): Отсюда видно, что наиболее узкими участками маршрута (на момент выполнения процедуры) являются Гамбург-Дюссельдорф-Берн-CERN. Следует иметь в виду, что канал МГУ-Гамбург был спутниковым и 500мс задержки здесь вносит удвоенное время распространения сигнала до спутника и обратно. Участок Гамбург-Дюссельдорф (X.25, квота
256кбит/с) был общим для потока данных из Германии в США. Передача IP
поверх X.25 также снижает эффективную широкополосность канала. Остальные связи обладают недостаточной пропускной способностью. Программа
ping
показывает для данных участков в часы пик высокую долю потерянных пакетов. Таким образом, имея карту связей и используя указанные процедуры, вы можете успешно диагностировать ситуацию в сети. Продвинутые же программисты могут легко написать свои диагностические программы, базирующиеся на ICMP
, как для локальной сети, так и для "окрестного" Интернет
. Когда маршрутизатор
не может доставить дейтаграмму по
месту назначения, он посылает отправителю сообщение "адресат недостижим" ( destination
unreachable). Формат такого сообщения показан ниже (на рис. 3.3). Поле
код содержит целое число
, проясняющее положение дел. Перечень кодов таких сообщений помещен в таблице 3.1 . Поле
MTU
на следующем этапе характеризует максимальную длину пакетов на очередном шаге пересылки. Эта информация
( MTU
) позволяет выбрать оптимальный размер пакета
. Так как в сообщении содержится Интернет
-заголовок и первые 64-бита дейтаграммы, легко понять, какой адрес
оказался недостижим. Этот тип ICMP
-сообщения посылается и в случае, когда дейтаграмма
имеет флаг DF=1
("не фрагментировать"), а фрагментация необходима. В поле
код в этом случае будет записано число 4. Если буфер
приема сообщения переполнен, ЭВМ посылает сообщение типа 4. Так как собственные часы различных ЭВМ имеют свое представление
о времени, протокол ICMP
, среди прочего, служит для синхронизации работы различных узлов, если это требуется (запросы временных меток). Протокол синхронизации
NTP
( network
time
protocol
) описан в RFC-1119. Когда дейтаграммы поступают слишком часто и принимающая сторона не справляется с этим потоком, отправителю может быть послано сообщение с требованием резко сократить информационный поток
(quenchзапрос). Снижение потока должно продолжаться до тех пор, пока не прекратятся quenchзапросы. Такое сообщение имеет формат, показанный на рис. 3.4 . В Internet
таблицы маршрутизации остаются без изменений достаточно долгое время, но иногда они все же меняются. Если маршрутизатор
обнаружит, что ЭВМ использует неоптимальный маршрут
, он может послать ей ICMP
- запрос
переадресации. При этом следует учитывать, что этой возможностью может воспользоваться и хакер
. Формат такого сообщения отображен на рисунке 3.5 . Поле
Internet-адрес
маршрутизатора содержит адрес
маршрутизатора, который ЭВМ должна использовать, чтобы посланная дейтаграмма
достигла места назначения, указанного в ее заголовке. В поле
internet
-заголовок кроме самого заголовка лежит 64 первых бита дейтаграммы, вызвавшей это сообщение. Поле
код специфицирует то, как нужно интерпретировать адрес
места назначения (см. табл. 3.1). Команды переадресации маршрутизатор
посылает только ЭВМ и никогда другим маршрутизаторам. Рассмотрим конкретный пример. Пусть некоторая ЭВМ на основе своей маршрутной таблицы посылает пакет маршрутизатору M1. Он, просмотрев свою маршрутную таблицу, находит, что пакет следует переслать маршрутизатору M2. Причем выясняется, что пакет из M1 в M2 следует послать через тот же интерфейс
, через который он попал в M1. Это означает, что M2 доступен и непосредственно для ЭВМ-отправителя. В такой ситуации M1 посылает ICMP
- запрос
переадресации ЭВМ-отправителю указанного пакета с тем, чтобы она внесла соответствующие коррективы в свою маршрутную таблицу (либо чтобы администратор
поменял IPадрес или маску ЭВМ). Маршрутная таблица
может загружаться из файла, формироваться менеджером сети, но может создаваться и в результате запросов и объявлений, посылаемых маршрутизаторами. После загрузки системы маршрутизатор
посылает широковещательный запрос
. Один или более маршрутизаторов посылают в ответ сообщения об имеющейся маршрутной информации. Кроме того, маршрутизаторы периодически (раз в 450600 сек.) широковещательно объявляют о своих маршрутах, что позволяет другим маршрутизаторам скорректировать свои маршрутные таблицы. В RFC-1256 описаны форматы ICMP
-сообщений такого рода (см. рис. 3.6). Из--за своей уязвимости данная технология в последнее время практически не используется. Поле
число адресов характеризует количество адресных записей в сообщении. Поле
длина
адреса содержит число 32-битных слов, необходимых для описания адреса маршрутизатора. Поле
время жизни предназначено для записи продолжительности жизни объявленных маршрутов (адресов) в секундах. По
умолчанию время жизни равно 30 мин. Поля уровень приоритета представляют собой меру приоритетности маршрута по
отношению к другим маршрутам данной
подсети. Чем больше этот код, тем выше приоритет. Маршрут
по
умолчанию имеет уровень приоритета 0. Формат запроса маршрутной информации (8 октетов, Хотя IPv4 не является надежным протоколом, на самом деле он предусматривает сообщения, которые будут отправлены в случае определенных ошибок. Эти сообщения отправляются, используя службы Протокола Контрольных Сообщений Интернета (протокол ICMP
). Цель этих сообщений состоит в том, чтобы обеспечить обратную связь о проблемах, связанных с обработкой пакетов IP при определенных условиях, но не для того, чтобы сделать IP надежным. Сообщения ICMP не являются обязательными и часто не разрешены из соображений безопасности. ICMP является протоколом обмена сообщениями стека TCP/IP
. ICMP обеспечивает контрольные сообщения и сообщения об ошибках и используется утилитами ping и traceroute . Хотя ICMP использует базовую поддержку IP, как высокоуровневый протокол, он фактически является отдельным протоколом Уровня 3 из стека TCP/IP. Типы сообщений ICMP - и причины, почему они отправляются, - обширны. Мы обсудим некоторые из более распространенных сообщений. Сообщения ICMP, которые могут быть отправлены, включают: Эхо-Сообщение ICMP может использоваться, чтобы определить, является ли узел рабочим. Локальный узел отправляет Эхо-запрос ICMP хосту. Хост, получающий эхо-сообщение, отвечает Эхо-ответом ICMP, как показано на рисунке. Это использование Эхо-сообщений ICMP является основой утилиты ping. Недостижимое Место назначения ICMP может использоваться, чтобы уведомить узел, что место назначения или служба недостижимы. Когда узел или шлюз получают пакет, который не удается доставить, он может отправить ICMP пакет Недостижимости Места назначения хосту, отправившему исходный пакет. Пакет Недостижимости Места назначения будет содержать коды, которые указывают, почему пакет не мог быть доставлен. Среди Кодов Недостижимости Места назначения можно назвать: 0 = недостижимая сеть 1 = недостижимый узел 2 = недостижимый протокол 3 = недостижимый порт Коды недостижимая сеть
и недостижимый узел
являются ответами от маршрутизатора, когда тот не может передать пакет. Если маршрутизатор получает пакет, для которого у него нет маршрута, он может ответить Недостижимым Местом назначения ICMP с кодом = 0, указывая на недостижимую сеть. Если маршрутизатор получает пакет, для которого он имеет присоединенный маршрут, но неспособен доставить пакет узлу в подключенной сети, маршрутизатор может ответить Недостижимым Местом назначения ICMP с кодом = 1, указывая, что сеть известна, но узел недостижим. Коды 2 и 3 (недостижимый протокол
и недостижимый порт
) используются конечным хостом, чтобы указать, что сегмент TCP или дейтаграмма UDP, содержавшаяся в пакете, не могли быть доставлены службе верхнего уровня. Когда конечный хост получает пакет PDU Уровня 4, который должен быть доставлен недоступной службе, хост может ответить узлу-отправителю ICMP сообщением Недостижимости Места назначения с кодом = 2 или с кодом = 3, указывая, что служба не доступна. Служба, вероятно, является недоступной, поскольку не запущен соответствующий демон, который предоставляет данную службу, либо потому что безопасность узла не позволяет доступ к службе. ICMP Сообщение Превышенного Времени используется маршрутизатором, чтобы указать, что пакет не может быть передан, поскольку TTL пакета истекло. Если маршрутизатор получает пакет и уменьшает поле TTL в пакете до нуля, он отбрасывает пакет. Маршрутизатор может также отправить ICMP Сообщение Превышенного Времени исходному узлу, чтобы сообщить ему причину, по которой пакет был отброшен. Маршрутизатор может использовать ICMP сообщение Перенаправления, чтобы уведомить узлы сети, что для определенного места назначения доступен лучший маршрут . Это сообщение может использоваться только тогда, когда исходный узел находится в той же самой физической сети, что и оба шлюза. Если маршрутизатор получает пакет, для которого у него есть маршрут и для которого следующий транзитный участок присоединен к тому же самому интерфейсу, с которого пакет прибыл, маршрутизатор может отправить сообщение Перенаправления ICMP исходному узлу. Это сообщение уведомит исходный узел о следующем транзитном участке, который содержался в маршруте таблицы маршрутизации. ICMP Сообщение Подавления Источника может использоваться, чтобы сообщить источнику временно прекратить отправлять пакеты. Если у маршрутизатора не будет достаточного количества буферного пространства, чтобы получать входящие пакеты, то маршрутизатор отбросит пакеты. Если маршрутизатору приходится это делать, он может также передать ICMP сообщение Подавления Источника узлам-отправителям для каждого сообщения, которое он отбрасывает. Конечный хост также может передать сообщение подавления источника, если дейтаграммы прибывают слишком быстро, чтобы быть обработанными. Когда хост получает ICMP сообщение Подавления Источника, он сообщает об этом Транспортному уровню . Далее хост-отправитель может использовать механизмы управления потоком TCP, чтобы скорректировать передачу.
нравиться может организовать все самостоятельно. Главное знать, что где находиться!
(ping…) с размером пакета по дефолту, можно точно сказать: если тебе пришло 32 байта,
то знай — это твой товарищ по Виндам, если 56, то это
обладатель UNIX машины!
5 — запрос на переадресацию (советую тщательно изучить именно этот тип ICMP,
так как он бывает очень полезен при проведении некоторых видов атак!).
пропингуешь самого себя, ты получишь столько пакетов сколько отправил! Почему, спросишь ты? Дело в том что «сырым» сокетам передаются не все ICMP пакеты, некоторые ядро обрабатывает самостоятельно, это небольшой недостаток нашей с тобой проги.
Зато если вместо IPPROTO_ICMP в сокете написать IPPROTO_RAW, тогда ты получишь доступ и к IGMP пакетам, а также ко всем пакетам в поле протокол которых стоит неизвестное ядру значение, попросту говоря все пакеты, которые ядро не знает как обрабатывать!
Рис.
3.1.
Таблица
3.1.
Типы и коды ICMP-сообщений
ICMP-сообщение
описание сообщения
Тип
код
0
Эхо-ответ (ping-отклик)
3
Адресат недостижим
0
* Сеть недостижима
1
* ЭВМ недостижима
2
* Протокол недоступен
3
* Порт недоступен
4
* Необходима фрагментация сообщения (установлен флаг DF)
5
* Маршрутизация отправителя нереализуема
6
* Сеть места назначения неизвестна
7
* ЭВМ места назначения неизвестна
8
* Исходная ЭВМ изолирована (устарело)
9
* Связь с сетью места назначения административно запрещена
10
* Связь с ЭВМ места назначения административно запрещена
11
* Сеть не доступна для данного вида сервиса (TOS)
12
* ЭВМ не доступна для данного вида сервиса (TOS)
13
* Связь административно запрещена с помощью фильтра
14
* Нарушение старшинства ЭВМ
15
* Дискриминация по старшинству
4
0
* Отключение источника при переполнении очереди (quench)
5
Переадресовать (изменить маршрут)
0
Переадресовать дейтаграмму в сеть (устарело)
1
Переадресовать дейтаграмму на ЭВМ
2
Переадресовать дейтаграмму для типа сервиса (ToS) и сети
3
Переадресовать дейтаграмму для типа сервиса и ЭВМ
8
0
Эхо запроса (ping-запрос)
9
0
Объявление маршрутизатора
10
0
Запрос маршрутизатора
11
Для дейтаграммы время жизни истекло (ttl=0):
0
*при передаче
1
* тайм-аут при сборке (случай фрагментации)
12
* Проблема с параметрами дейтаграммы
0
* Ошибка в IP-заголовке
1
* Отсутствует необходимая опция
13
Запрос временной метки
14
Временная метка-отклик
15
Запрос информации (устарел)
16
Информационный отклик (устарел)
17
Запрос адресной маски
18
Отклик на запрос адресной маски
Рис.
3.2.
Рис.
3.2a.
Таблица
3.1.1.
traceroute to crnvma cern ch
(128 141 2 4) 30 hops max, 40 byte packets
1
itep-fddi-bbone
(193.124.224.50) 3 ms 2 ms 3 ms
2
msu
- tower
.moscow.ru.radio- msu
.net
(193.124.137.13) 3 ms 3 ms 3 ms
3
npi- msu
.moscow.ru.radio- msu
.net
(193.124.137.9) 27 ms 3 ms 9 ms
4
desy.hamburg.de.radio- msu
.net
(193.124.137.6) 556 ms 535 ms 535 ms
5
* 188.1.133.56
(188.1.133.56) 637ms 670ms
6
duesseldorf2.empb.net
(193.172.4.12) 740ms(ttl=59!) 839ms(ttl=59!) 2066ms(ttl=59!)
7
bern3.empb.net
(193.172.4.30) 2135ms (ttl=58!) 1644ms (ttl=58!) 1409ms (ttl=58!)
8
cernh3.euro-hep.net
(193.172.24.10) 1808ms 1508ms 1830ms
9
cgate1.cern.ch
(192.65.185.1) 1116ms 1270ms 1278ms
10
crnvma.cern.ch
(128.141.2.4) 1132ms 1362ms 1524ms
Рис.
3.3.
Формат ICMP-сообщения "адресат недостижим"
Рис.
3.4.
Рис.
3.5.
Рис.
3.6.
Подтверждение узла
Недостижимое Место назначения или Служба
Превышенное время
Перенаправление маршрута
Подавление Источника
