ICMP протокол
Протокол ICMP является одним из компонентов стека TCP/IP (Transmission Control Protocol/Internet Protocol — протокол управления передачей/протокол сети Internet), который компенсирует неспособность протокола IP гарантированно доставлять данные. Вместе с тем протокол ICMP не устраняет ненадежность передачи данных протоколом IP. Он лишь уведомляет отправителя данных о том, что при их доставке возникли проблемы.
На рисунке показано место протокола ICMP в модели TCP/IP.
Протокол ICMP является механизмом отправки сообщений об ошибках для протокола IP.
Если при доставке дейтаграммы происходит ошибка, протокол ICMP сообщает об этом отправителю дейтаграммы. Например, предположим, что PC1, показанный на следующем рисунке, посылает дейтаграмму PC4. Если соответствующий интерфейс маршрутизатора Вorder выходит из строя, этот маршрутизатор использует протокол ICMP для отправки PC1 сообщения о том, что доставка дейтаграммы оказалась невозможной. Протокол ICMP не устраняет возникшую в сети проблему.
Сообщения протокола ICMP доставляются с использованием протокола IP.
ICMP-сообщения инкапсулируются в дейтаграммы, точно так же, как и обычные данные, доставляемые по протоколу IP. В таблице показана инкапсуляция ICMP-пакета в поле данных IP-дейтаграммы. Заголовок фрейма может формироваться по протоколу локальной сети, такому, как Ethernet, или по протоколу распределенной сети, такому, например, как HDLC.
Заголовок фрейма Заголовок IP-дейтаграммы Заголовок протокола ICMP Данные протокола ICMP
Заголовок фрейма Заголовок IP-дейтаграммы Поле данных IP-дейтаграммы
Заголовок фрейма Поле данных IP-дейтаграммы
Заголовок фрейма Поле данных фрейма
Когда данные поступают на сетевой уровень, они инкапсулируются в дейтаграмму. После этого дейтаграмма и инкапсулированные в ней данные вновь инкапсулируются во фрейм на канальном уровне. Сообщения протокола ICMP содержат в заголовках свою собственную информацию. Однако эта информация вместе с данными протокола ICMP инкапсулируется в дейтаграмму и передается таким же образом, что и все остальные данные. Поэтому сообщения об ошибках также подвержены риску быть утерянными при передаче. Таким образом, может возникнуть ситуация, в которой сами сообщения об ошибках могут создать новые ошибки, что лишь усложнит ситуацию с затором в уже работающей со сбоями сети. По этой причине ошибки, созданные сообщениями ICMP, не генерируют свои собственные ICMP-сообщения. Следовательно, возможен случай, когда при доставке дейтаграммы происходит ошибка, но о ней не сообщается отправителю данных.
Бодание с WinpCap и отправка ping’ов
Все знают команду ping, которая предназначена для отправки эхо-запроса и получения эхо-ответа. Мы же решили, что системного ping’a нам мало и попытались реализовать свою программу ping.
Инструментом для реализации был компилятор С++ и библиотечка WinPcap. WinPcap — Низкоуровневая библиотека для взаимодействия с драйверами сетевых интерфейсов.
И так начинаем сборку ICMP-пакета.
Формат ICMP-пакета успешно был взят с Wiki.
| Октет | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0—3 | Тип | Код | Контрольная сумма | |||||||||||||||||||||||||||||
| … | Данные (формат зависит от значений полей «Код» и «Тип») | |||||||||||||||||||||||||||||||
u_char packet[1514]; //собственно наш пакет //MAC-адрес получателя packet[0]=0x08; packet[1]=0x00; packet[2]=0x27; packet[3]=0x4c; packet[4]=0x18; packet[5]=0xDA; ////MAC-адрес отправителя packet[6]=0x08; packet[7]=0x00; packet[8]=0x27; packet[9]=0xca; packet[10]=0xb8; packet[11]=0x44; //Формирование IP-заголовка packet[12]=0x08; packet[13]=0x00; packet[14]=0x45; packet[15]=0x00; //Длинна пакета *(WORD *)&packet[16] = htons(1500); packet[18]=0x11; //id packet[19]=0x22; packet[20]=0; //фрагментацию отключаем packet[21]=0; packet[22]=0x80; //ttl packet[23]=1; //icmp packet[24]=0; //контрольная сумма packet[25]=0; //От кого packet[26]=192; packet[27]=168; packet[28]=1; packet[29]=1; //куда packet[30]=192; packet[31]=168; packet[32]=1; packet[33]=128; chS=ComputeIPChecksum(&packet[14],20); //считаем контрольную сумму printf("%x\n", chS); *(WORD *)&packet[24] = chS; //**************************************************** packet[34]=8; //icmp packet[35]=0; packet[36]=0x29; //csum packet[37]=0x31; packet[38]=0x11; //icmp packet[39]=0x11; packet[40]=0x22; //csum packet[41]=0x22; chS=ComputeIPChecksum(&packet[34],8); printf("%x\n", chS); for(i=42; i //отправляем if (pcap_sendpacket(fp, // Adapter packet, // buffer with the packet 1514 // size ) != 0)
Результаты посмотрим на следующем рисунке.
Видим запрос и ответ. Все ОК.
А что, если поставить левый MAC-адрес отправителя?
А что, если поставить левый IP-адрес отправителя?
А что, если MAC = FF-FF-FF-FF-FF-FF?
Можно пойти на Wiki и увидеть следующее:
ICMP-пакеты никогда не генерируются в ответ на IP-пакеты с широковещательным или групповым адресом, чтобы не вызывать перегрузку в сети (так называемый «широковещательный шторм»).
Попробуем нарушить это правило. С машины с IP 192.168.1.2 будем отправлять ping на 192.168.1.3, при этом IP отправителя будет равен 192.168.1.1, а MAC отправителя FF-FF-FF-FF-FF-FF.
Оказалось, что мы заставили 192.168.1.3 отвечать 192.168.1.1, при том, что последний этого не хотел. Самое интересное, то, что это был широковещательный ping и он прошел!
Смотрим что на других машинах. 
На других машинках мы ловим широковещательные запросы.
А раз так, то есть повод написать в программе while(1) и наслаждаться DOS-атакой.
Список литературы:
Одом У. — CISCO Официальное руководство по подготовке к сертификационным экзаменам CCENTCCNA ICND1 — 2010
ru.wikipedia.org
Общие сведения о командах Ping и Traceroute
В этой статье рассматривается использование команд ping и traceroute. Приведенный в данном документе более подробный обзор результатов выполнения этих команд, был получен с помощью некоторых команд debug.
Базовые сведения
В данном документе используется простая конфигурация, представленная ниже и используемая в качестве примера
Команда ping
- Является ли удаленный хост активным или неактивным;
- Задержки приема-передачи при взаимодействии с хостом;
- Потери пакетов.
- эхо-запрос достигает места назначения;
- опрашиваемое устройство может отправить эхо-ответ обратно источнику в рамках заданного времени, называемого временем ожидания (тайм-аутом). Значение тайм-аута по умолчанию для маршрутизаторов Cisco равно двум секундам.
Router1#debug ip packet detail
IP packet debugging is on (detailed)
Router1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms
Router1#
Jan 20 15:54:47.487: IP: s=12.0.0.1 (local), d=12.0.0.2 (Serial0), len 100,
sending
Jan 20 15:54:47.491: ICMP type=8, code=0
!— Это ICMP пакет, отправленный из 12.0.0.1 в 12.0.0.2.
!— ICMP тип=8 соответствует эхо-сообщению.
Jan 20 15:54:47.523: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 100,
rcvd 3
Jan 20 15:54:47.527: ICMP type=0, code=0
!— Это ответ, полученный от 12.0.0.2.
!— ICMP тип=0 соответствует эхо-ответу.
!— По умолчанию число повторов равно 5, поэтому будет пять
!— эхо-запросов и пять эхо-ответов.
В приведенной ниже таблице перечислены возможные значения типа ICMP-протокола.
Тип ICMP-протокола
Символьная константа
цель назначения недостижима
код 0 = сеть недостижима
1 = хост недостижим
2 = протокол недостижим
3 = порт недостижим
4 = необходима фрагментация и установка DF-бита
5 = исходный маршрут недоступен
отключение источника сообщения при перегрузке с предварительным возвратом сообщения
перенаправление
код 0 = перенаправление дейтаграмм для сети
1 = перенаправление дейтаграмм для хоста
2 = перенаправление дейтаграмм для типа службы или сети
3 = перенаправление дейтаграмм для типа службы и хоста
альтернативный адрес
объявление маршрутизатора
запрос маршрутизатора
истечение времени ожидания
код 0 = истекло время существования пакета во время его передачи 1 = превышено время сборки фрагментов
проблема параметра
запрос временной метки
ответ на запрос о временной метке
информационный запрос
ответ на информационный запрос
запрос маски
ответ на запрос маски
ошибка преобразования
мобильное перенаправление
В нижеприведенной таблице содержатся сведения о символах, которые могут содержаться в результатах выполнения команды ping:
Отключение источника сообщения при перегрузке с предварительным возвратом сообщения (цель назначения перегружена).
Причины неудачного выполнения команды ping
Если не удается успешно выполнить команду ping, то причиной этому могут быть:
Проблема маршрутизации
Далее приведен пример неудачного выполнения команды ping, определения проблемы и мер, необходимых для ее устранения.
Данный сценарий объясняется с помощью схемы топологии сети, приведенной ниже:
Router1#
!
!
interface Serial0
ip address 12.0.0.1 255.255.255.0
no fair-queue
clockrate 64000
!
!
Router2#
!
!
interface Serial0
ip address 23.0.0.2 255.255.255.0
no fair-queue
clockrate 64000
!
interface Serial1
ip address 12.0.0.2 255.255.255.0
!
!
Router3#
!
!
interface Serial0
ip address 34.0.0.3 255.255.255.0
no fair-queue
!
interface Serial1
ip address 23.0.0.3 255.255.255.0
!
!
Router4#
!
!
interface Serial0
ip address 34.0.0.4 255.255.255.0
no fair-queue
clockrate 64000
!
!
В приведенном ниже примере производится опрос маршрутизатора 4 с маршрутизатора 1 с помощью команды ping:
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds:
.
Success rate is 0 percent (0/5)
Давайте внимательнее посмотрим на произошедшее:
Router1#debug ip packet
IP packet debugging is on
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds:
Jan 20 16:00:25.603: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable.
Jan 20 16:00:27.599: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable.
Jan 20 16:00:29.599: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable.
Jan 20 16:00:31.599: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable.
Jan 20 16:00:33.599: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable.
Success rate is 0 percent (0/5)
Поскольку протоколы маршрутизации не используются в маршрутизаторе 1, он не знает, куда посылать пакеты и создает сообщение о невозможности маршрутизации.
Добавим маршрутизатору 1 статический маршрут:
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ip route 0.0.0.0 0.0.0.0 Serial0
Теперь у нас имеется:
Router1#debug ip packet detail
IP packet debugging is on (detailed)
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
Jan 20 16:05:30.659: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:05:30.663: ICMP type=8, code=0
Jan 20 16:05:30.691: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:05:30.695: ICMP type=3, code=1
Jan 20 16:05:30.699: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:05:30.703: ICMP type=8, code=0
Jan 20 16:05:32.699: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:05:32.703: ICMP type=8, code=0
Jan 20 16:05:32.731: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:05:32.735: ICMP type=3, code=1
Jan 20 16:05:32.739: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:05:32.743: ICMP type=8, code=0
Теперь оценим неисправности, возникающие на маршрутизаторе 2:
Router2#debug ip packet detail
IP packet debugging is on (detailed)
Router2#
Jan 20 16:10:41.907: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable
Jan 20 16:10:41.911: ICMP type=8, code=0
Jan 20 16:10:41.915: IP: s=12.0.0.2 (local), d=12.0.0.1 (Serial1), len 56, sending
Jan 20 16:10:41.919: ICMP type=3, code=1
Jan 20 16:10:41.947: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable
Jan 20 16:10:41.951: ICMP type=8, code=0
Jan 20 16:10:43.943: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable
Jan 20 16:10:43.947: ICMP type=8, code=0
Jan 20 16:10:43.951: IP: s=12.0.0.2 (local), d=12.0.0.1 (Serial1), len 56, sending
Jan 20 16:10:43.955: ICMP type=3, code=1
Jan 20 16:10:43.983: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable
Jan 20 16:10:43.987: ICMP type=8, code=0
Jan 20 16:10:45.979: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable
Jan 20 16:10:45.983: ICMP type=8, code=0
Jan 20 16:10:45.987: IP: s=12.0.0.2 (local), d=12.0.0.1 (Serial1), len 56, sending
Jan 20 16:10:45.991: ICMP type=3, code=1
Маршрутизатор1 правильно отправляет свои пакеты на маршрутизатор 2, но маршрутизатор 2 не знает, как получить доступ к адресу 34.0.0.4. Маршрутизатор 2 отправляет Маршрутизатору 1 сообщение «unreachable ICMP» («недоступный ICMP-протокол»).
Теперь разрешите использование протокола маршрутизации информации (RIP-протокол) на маршрутизаторе 2 и маршрутизаторе 3.
Router2#
router rip
network 12.0.0.0
network 23.0.0.0
Router3#
router rip
network 23.0.0.0
network 34.0.0.0
Router1#debug ip packet
IP packet debugging is on
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds:
Jan 20 16:16:13.367: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending.
Jan 20 16:16:15.363: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending.
Jan 20 16:16:17.363: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending.
Jan 20 16:16:19.363: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending.
Jan 20 16:16:21.363: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending.
Success rate is 0 percent (0/5)
Это немного улучшает ситуацию. Маршрутизатор 1 отправляет пакеты на маршрутизатор 4, но не получает никакого ответа от него.
Рассмотрим, какие проблемы могли возникнуть на маршрутизаторе 4:
Router4#debug ip packet
IP packet debugging is on
Router4#
Jan 20 16:18:45.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:18:45.911: IP: s=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable
Jan 20 16:18:47.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:18:47.907: IP: s=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable
Jan 20 16:18:49.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:18:49.907: IP: s=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable
Jan 20 16:18:51.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:18:51.907: IP: s=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable
Jan 20 16:18:53.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:18:53.907: IP: s=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable
Маршрутизатор 4 получает ICMP-пакеты и пытается отправить ответ на адрес 12.0.0.1, но так как у него нет маршрута в эту сеть, эта попытка терпит неудачу.
Добавим маршрутизатору 4 статический маршрут:
Router4(config)#ip route 0.0.0.0 0.0.0.0 Serial0
Теперь он работает правильно и обе стороны имеют доступ друг к другу:
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds: .
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
Недоступность интерфейса
Эта ситуация возникает в случаях, когда интерфейс перестает работать. В приведенном ниже примере производится опрос маршрутизатора 4 с маршрутизатора 1 с помощью команды ping:
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds: U.U.U
Success rate is 0 percent (0/5)
Поскольку маршрутизация исправна, то устранение неполадок будет выполняться в пошаговом режиме. В начале попытаемся применить команду ping к маршрутизатору 2:
Router1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Из приведенных выше данных видно, что источник проблемы находится между маршрутизатором 2 и маршрутизатором 3. Одной из возможных причин может являться то, что последовательный интерфейс на маршрутизаторе 3 был отключен:
Router3#show ip interface brief
Serial0 34.0.0.3 YES manual up up
Serial1 23.0.0.3 YES manual administratively down down
Эта проблема легко устранима:
Router3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router3(config)#interface s1
Router3(config-if)#no shutdown
Router3(config-if)#
Jan 20 16:20:53.900: %LINK-3-UPDOWN: Interface Serial1, changed state to up
Jan 20 16:20:53.910: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
Команда Access-list
В этом сценарии необходимо разрешить только трафику telnet поступать на маршрутизатор 4 через интерфейс Serial0.
Router4(config)# access-list 100 permit tcp any any eq telnet
Router4(config)#interface s0
Router4(config-if)#ip access-group 100 in
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#access-list 100 permit ip host 12.0.0.1 host 34.0.0.4
Router1(config)#access-list 100 permit ip host 34.0.0.4 host 12.0.0.1
Router1(config)#end
Router1#debug ip packet 100
IP packet debugging is on Router1#debug ip icmp
ICMP packet debugging is on
При попытке проверить доступность маршрутизатора 4 с помощью команды ping будет получен следующий результат:
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds: U.U.U
Success rate is 0 percent (0/5)
Jan 20 16:34:49.207: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:34:49.287: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:34:49.291: ICMP: dst (12.0.0.1) administratively prohibited unreachable rcv from 34.0.0.4
Jan 20 16:34:49.295: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:34:51.295: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:34:51.367: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:34:51.371: ICMP: dst (12.0.0.1) administratively prohibited unreachable rcv from 34.0.0.4
Jan 20 16:34:51.379: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
В конце команды access-list всегда существует неявное условие «deny all» («запретить всё»). Это означает, что ICMP-пакеты, поступающие на интерфейс Serial 0 маршрутизатора 4, отклоняются, а маршрутизатор 4, как показано в результате выполнения команды debug, отправляет источнику исходного пакета сообщение — «administratively prohibited unreachable» («доступ запрещен административно»). Решением проблемы является добавление в команду access-list следующей строки:
Router4(config)#access-list 100 permit icmp any any
Проблема с протоколом разрешения адресов (ARP-протокол)
В данном подразделе приведен пример подключения через протокол Ethernet:
Router4#ping 100.0.0.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.5, timeout is 2 seconds:
Jan 20 17:04:05.167: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, sending
Jan 20 17:04:05.171: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, encapsulation failed.
Jan 20 17:04:07.167: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, sending
Jan 20 17:04:07.171: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, encapsulation failed.
Jan 20 17:04:09.175: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, sending
Jan 20 17:04:09.183: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, encapsulation failed.
Jan 20 17:04:11.175: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, sending
Jan 20 17:04:11.179: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, encapsulation failed.
Jan 20 17:04:13.175: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, sending
Jan 20 17:04:13.179: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, encapsulation failed.
Success rate is 0 percent (0/5)
Router4#
В данном примере команда ping не работает из-за «неудачной инкапсуляции». Это означает, что маршрутизатору известно, на какой интерфейс следует отправлять пакет, но неизвестно, каким образом это сделать. В этом случае необходимо понять принцип функционирования ARP-протокола.
В основном, ARP — это протокол, используемый для сопоставления адреса второго уровня (MAC-адрес) с адресом третьего уровня (IP-адрес). Для проверки этого отображения можно использовать команду show arp:
Router4#show arp
Вернемся к проблеме неудачной инкапсуляции. Более подробные сведения об этой проблеме можно получить с помощью команды debug:
Router4#debug arp
ARP packet debugging is on
Router4#ping 100.0.0.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.5, timeout is 2 seconds:
Jan 20 17:19:43.843: IP ARP: creating incomplete entry for IP address: 100.0.0.5
interface Ethernet0
Jan 20 17:19:43.847: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d,
dst 100.0.0.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:45.843: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d,
dst 100.0.0.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:47.843: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d,
dst 100.0.0.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:49.843: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d,
dst 100.0.0.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:51.843: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d,
dst 100.0.0.5 0000.0000.0000 Ethernet0.
Success rate is 0 percent (0/5)
В представленном выше результате выполнения команды показано, что маршрутизатор 4 транслирует пакеты, пересылая их на широковещательный Ethernet-адрес FFFF.FFFF.FFFF. В данном случае 0000.0000.0000 означает, что маршрутизатор 4 ищет MAC-адрес целевого устройства 100.0.0.5. Поскольку в этом примере он не знает MAC-адреса во время выполнения ARP-запроса, то он отсылает широковещательные кадры с интерфейса Ethernet 0 с адресом 0000.0000.000 в качестве шаблона и запрашивает, какой MAC-адрес соответствует IP-адресу 100.0.0.5. Если маршрутизатор не получает ответа, то соответствующий адрес в результате выполнения команды show arp помечается как неполный:
Router4#show arp
По прошествии определенного периода времени сведения о неполноте удаляются из ARP-таблицы. Пока соответствующий MAC-адрес отсутствует в ARP-таблице, выполнение команды ping будет заканчиваться неудачей в результате «неудачной инкапсуляции».
Задержка
По умолчанию если ответ от удаленного оконечного сетевого устройства не получен в течение двух секунд, то выполнение команды ping заканчивается неудачей:
Router1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
.
Success rate is 0 percent (0/5)
В сетях с низкой скоростью передачи данных или с большой задержкой двух секунд времени ожидания может оказаться недостаточным. Это значение по умолчанию можно изменить с помощью выполнения расширенной команды ping:
Router1#ping
Protocol [ip]:
Target IP address: 12.0.0.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]: 30
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 30 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 1458/2390/6066 ms
В вышеприведенном примере увеличение времени ожидания привело к успешному выполнению команды ping.
Примечание. Среднее время приема-передачи составляет более двух секунд.
Исправление адреса-источника
В данном подразделе приведен пример типичной ситуации:
На маршрутизаторе 1 добавлен интерфейс LAN:
Router1(config)#interface e0
Router1(config-if)#ip address
Router1(config-if)#ip address 20.0.0.1 255.255.255.0
Из узла локальной сети (LAN) можно выполнить команду ping для маршрутизатора 1. Команду ping можно направить с маршрутизатора 1 на маршрутизатор 2. Но к маршрутизатору 2 невозможно применить команду ping из узла локальной сети (LAN).
Можно посылать пакеты проверки связи с маршрутизатора 1 на маршрутизатор 2, так как по умолчанию IP-адрес исходящего интерфейса используется в качестве адреса источника в ICMP-пакете. Маршрутизатор 2 не располагает сведениями об этой новой локальной сети (LAN). Если маршрутизатор должен ответить на пакет приходящий из этой сети, то он не знает как обрабатывать этот пакет.
Router1#debug ip packet
IP packet debugging is on
Router1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/9 ms
Router1#
Jan 20 16:35:54.227: IP: s=12.0.0.1 (local), d=12.0.0.2 (Serial0), len 100, sending
Jan 20 16:35:54.259: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 100, rcvd 3
Выходные данные из вышеприведенного примера работают, потому что адрес источника отправляемого пакета равен s = 12.0.0.1. Если необходимо смоделировать пакет, поступающий из локальной сети, то следует использовать расширенную команду ping:
Router1#ping
Protocol [ip]:
Target IP address: 12.0.0.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 20.0.0.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
Jan 20 16:40:18.303: IP: s=20.0.0.1 (local), d=12.0.0.2 (Serial0), len 100, sending.
Jan 20 16:40:20.303: IP: s=20.0.0.1 (local), d=12.0.0.2 (Serial0), len 100, sending.
Jan 20 16:40:22.303: IP: s=20.0.0.1 (local), d=12.0.0.2 (Serial0), len 100, sending.
Jan 20 16:40:24.303: IP: s=20.0.0.1 (local), d=12.0.0.2 (Serial0), len 100, sending
Jan 20 16:40:26.303: IP: s=20.0.0.1 (local), d=12.0.0.2 (Serial0), len 100, sending.
Success rate is 0 percent (0/5)
Теперь исходным адресом является IP-адрес 20.0.0.1, который не функционирует! Пакеты могут быть переданы, но ответа на них не поступает. Для устранения этой проблемы необходимо добавить маршрут к IP-адресу 20.0.0.0 в маршрутизаторе 2.
Основное правило состоит в том, что устройству, получившему запрос о проверке доступности, должен быть известен способ отправки ответа источнику этого запроса.
Команда traceroute
Команда traceroute используется для отыскания маршрутов, которые будут использоваться при передаче пакетов к сетевому узлу назначения. Устройство (например, маршрутизатор или персональный компьютер) отправляет последовательность UDP-дейтаграмм на недопустимый адрес порта на удаленном хосте.
Отправляются три дейтаграммы со значением поля TTL (время существования) равным единице. Значение времени существования равное единице означает, что дейтаграмма перестанет существовать после достижения первого маршрутизатора на маршруте, а затем этот маршрутизатор отправит ICMP-сообщение о превышении времени существования, указывающее на истечение времени существования.
Теперь отправляются другие три UDP-сообщения со значением времени существования равным двум, что является причиной, по которой второй маршрутизатор возвращает ICMP-сообщение о превышении времени существования. Этот процесс продолжается до тех пор, пока пакеты не достигают другого пункта назначения. Так как эти дейтаграммы пытаются получить доступ к неверному порту на узле назначения, то этот узел возвращает ICMP-сообщения о недоступном порте. Это событие сигнализирует о необходимости завершить выполнение программы Traceroute.
После этого необходимо записать источник каждого ICMP-сообщения о превышении времени существования для обеспечения трассировки пути, по которому пакет попадает к адресату.
Router1#traceroute 34.0.0.4
Type escape sequence to abort.
Tracing the route to 34.0.0.4
1 12.0.0.2 4 msec 4 msec 4 msec
2 23.0.0.3 20 msec 16 msec 16 msec
3 34.0.0.4 16 msec * 16 msec
Jan 20 16:42:48.611: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.615: UDP src=39911, dst=33434
Jan 20 16:42:48.635: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.639: ICMP type=11, code=0
!— ICMP-сообщение об истечении времени от маршрутизатора 2.
Jan 20 16:42:48.643: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.647: UDP src=34237, dst=33435
Jan 20 16:42:48.667: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.671: ICMP type=11, code=0
Jan 20 16:42:48.675: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.679: UDP src=33420, dst=33436
Jan 20 16:42:48.699: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.703: ICMP type=11, code=0
Это первая последовательность пакетов отправляемых с параметром TTL = 1. Первый маршрутизатор (в данном случае маршрутизатор 2 (12.0.0.2)) игнорирует пакет и посылает назад отправителю (12.0.0.1) ICMP-сообщение типа 11. Это соответствует сообщению о превышении времени существования.
Jan 20 16:42:48.707: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.711: UDP src=35734, dst=33437
Jan 20 16:42:48.743: IP: s=23.0.0.3 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.747: ICMP type=11, code=0
!— ICMP-сообщение об истечении времени от маршрутизатора 3.
Jan 20 16:42:48.751: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.755: UDP src=36753, dst=33438
Jan 20 16:42:48.787: IP: s=23.0.0.3 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.791: ICMP type=11, code=0
Jan 20 16:42:48.795: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.799: UDP src=36561, dst=33439
Jan 20 16:42:48.827: IP: s=23.0.0.3 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.831: ICMP type=11, code=0
Тот же самый процесс происходит и для маршрутизатора 3 (23.0.0.3) с параметром TTL = 2:
Jan 20 16:42:48.839: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.843: UDP src=34327, dst=33440
Jan 20 16:42:48.887: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.891: ICMP type=3, code=3
!— Сообщение о недоступности порта от маршрутизатора 4.
Jan 20 16:42:48.895: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.899: UDP src=37534, dst=33441
Jan 20 16:42:51.895: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:51.899: UDP src=37181, dst=33442
Jan 20 16:42:51.943: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:51.947: ICMP type=3, code=3
Маршрутизатор 4 можно достичь с параметром TTL = 3. На этот раз, поскольку порт недоступен, маршрутизатор 4 оправляет обратно на маршрутизатор 1 ICMP-сообщение с типом равным 3, сообщение о недоступности места назначения и код равный 3, означающий, что порт недостижим.
В нижеприведенной таблице содержатся символы, которые могут отображаться в результате выполнения команды traceroute.
Текстовые символы IP-трассировки
| Символ | Описание |
| nn msec | Время приема-передачи в миллисекундах для заданного числа тестовых сообщений при проверке каждого узла сети |
| * | Время жизни тестового сообщения |
| A | Административно запрещено (например, список контроля доступа) |
| Q | Отключение источника сообщения при перегрузке с предварительным возвратом сообщения (цель назначения перегружена) |
| I | Пользовательская проверка на прерывание |
| U | Порт недостижим |
| H | Хост недостижим |
| N | Сеть недостижима |
| P | Протокол недостижим |
| T | Тайм-аут |
| ? | Неизвестный тип пакета |
Пропускная способность
С помощью команд ping и traceroute можно получить время приема-передачи (RTT). Это время, необходимое для отправки эхо-пакета и получения ответа. Полезно иметь приблизительное представление о задержке в канале. Однако получаемые значения недостаточны точны для оценки пропускной способности.
Если адресом назначения является адрес самого маршрутизатора, то для этих пакетов должно быть произведено перенаправление. Процессор должен обработать данные из такого пакета и отправить ответ. Это не основная цель маршрутизатора. По определению, маршрутизатор спроектирован для маршрутизации пакетов. Ответ на запрос эхо-теста предлагается в качестве службы негарантированной доставки (best-effort – по возможности).
В качестве примера приведем результат выполнения команды ping между маршрутизатором 1 и маршрутизатором 2:
Router1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Время приема-передачи (RTT) равно примерно четырем миллисекундам. После разрешения некоторых ресурсозатратных функций на маршрутизаторе 2 попытайтесь отправить команду ping с маршрутизатора 2 на маршрутизатор 1.
Router1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/25/28 ms
Время приема-передачи (RTT) значительно выросло. Маршрутизатор 2 очень занят, а ответ на запрос проверки связи не является его первостепенной задачей.
Лучшим способом проверки пропускной способности маршрутизатора является использование трафика, проходящего через него:
После чего маршрутизатором производится быстрое перенаправление пакетов и их обработка с наивысшим приоритетом. Для иллюстрации этого вернемся к основной сети:
Произведем опрос маршрутизатора 3 с маршрутизатора 1 с помощью команды ping:
Router1#ping 23.0.0.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 23.0.0.3, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms
Трафик проходит через маршрутизатор 2 и быстро коммутируется.
Теперь разрешим ресурсозатратные функции на маршрутизаторе 2:
Router1#ping 23.0.0.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 23.0.0.3, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/36 ms
Никаких различий почти не существует. Это связано с тем, что теперь на маршрутизаторе 2 пакеты обрабатываются на уровне прерывания.
Использование команды Debug
Использованные до сих пор команды debug давали нам понимание того, что происходит при использовании команды ping или traceroute. Они также могут оказаться полезными при поиске и устранении неполадок. Однако в реальных условиях отладка должна производиться с осторожностью. Если процессор не достаточно производительный или существует много перенаправляемых пакетов, то это может легко привести к падению производительности сетевого устройства. Существует пара методов для минимизации влияния выполнения команды debug на маршрутизатор. Один из способов — использование списков контроля доступа для ограничения трафика, который требуется контролировать. Ниже представлен пример этого:
Router4#debug ip packet?
Access list
Access list (expanded range)
detail Print more debugging detail
Router4#configure terminal
Router4(config)#access-list 150 permit ip host 12.0.0.1 host 34.0.0.4
Router4(config)#^Z
Router4#debug ip packet 150
IP packet debugging is on for access list 150
Router4#show debug
Generic IP:
IP packet debugging is on for access list 150
Router4#show access-list
Extended IP access list 150
permit ip host 12.0.0.1 host 34.0.0.4 (5 matches)
При этой конфигурации маршрутизатор 4 печатает сообщения отладки, соответствующие только списку контроля доступа 150. Команда ping, поступающая от маршрутизатора 1, приводит к отображению следующего сообщения:
Router4#
Jan 20 16:51:16.911: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:51:17.003: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:51:17.095: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:51:17.187: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:51:17.279: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Пакеты, не соответствующие списку контроля доступа, маршрутизатором 4 не отображаются. Для их просмотра необходимо добавить следующие команды:
Router4(config)#access-list 150 permit ip host 12.0.0.1 host 34.0.0.4
Router4(config)#access-list 150 permit ip host 34.0.0.4 host 12.0.0.1
После этого отобразятся следующие результаты:
Jan 20 16:53:16.527: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:53:16.531: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending
Jan 20 16:53:16.627: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:53:16.635: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending
Jan 20 16:53:16.727: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:53:16.731: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending
Jan 20 16:53:16.823: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:53:16.827: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending
Jan 20 16:53:16.919: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:53:16.923: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending
Другим способом минимизации воздействия команды debug является помещение отладочных сообщений в буфер и их вывод после выключения отладки с помощью команды show log:
Router4#configure terminal
Router4(config)#no logging console
Router4(config)#logging buffered 5000
Router4(config)#^Z
Router4#debug ip packet
IP packet debugging is on
Router4#ping 12.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.1, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/37 ms
Router4#undebug all
All possible debugging has been turned off
Router4#show log
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: disabled
Monitor logging: level debugging, 0 messages logged
Buffer logging: level debugging, 61 messages logged
Trap logging: level informational, 59 message lines logged
Log Buffer (5000 bytes):
Jan 20 16:55:46.587: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending
Jan 20 16:55:46.679: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Как показано выше, команды ping и traceroute являются очень полезными при поиске и устранении проблем доступа к сети. Кроме того, они очень просты в применении. Так как эти две команды широко используются сетевыми инженерами, то понимание принципов их функционирования является очень важным при поиске и устранении неисправностей подключения к сети.
Есть вопросы?
Обращайтесь в «Аквилон-А», чтобы узнать подробности и получить именно то, что вам требуется.
- Статьи
- Решения эконом класса
- Маршрутизаторы Linksys
- Коммутаторы Linksys
- Маршрутизаторы
- Cisco 800, Cisco 1800,
- Cisco 2800, Cisco 3800
- Catalyst Express 500, Catalyst 2960,
- Catalyst 3560, Catalyst 3750
- Cisco 500 Series Wireless Express
- Cisco Aironet 1130AG Series
- Cisco Aironet 1240AG Series
- Cisco Aironet 1310 и 1410 Series
- Контроллер сети Cisco 2100 Series
- Cisco ASA
- Маршрутизаторы
- Cisco 7200, Cisco 7600
- Catalyst 4500, Catalyst 4900, Catalyst 6500
- Контроллер сети Cisco 4400 Series
- Cisco ASA
- IP-видеокамеры
- Серия 2500, Серия 4000
- Телефоны IP Phones 7900 Series
- Приложения:
- Unified Com Mgr Express
- Unified Com Mgr BE
- Smart Business Com System
- Unity Express, Unity Connection
Чтобы связаться с нашими менеджерами, Вы можете:
сделать заказ, задать любой вопрос
позвонить по телефону 977 422-05-25 (многоканальный)Идентификация утилит ICMP
В настоящее время существует несколько специальных утилит, которые позволяют создавать ICMP датаграммы с заданными параметрами. Они могут использоваться для различных целей: собственно детектирование хоста (в том числе более продвинутое, чем просто ping), идентификация ОС и т.д. В данной статье будут рассматриваться особенности утилит, с помощью которых создаются различные ICMP-датаграммы. Если мы сможем определить используемую в конкретном случае утилиту, то соответственно сможем определить и тип ОС, на которой она выполняется (особенности ОС так или иначе будут влиять на ее работу).
В наше поле зрения попадут следующие утилиты ICMP:
— ‘ping’ , из набора iputils, идущего вместе с RedHat Linux ( kernel 2.2.14)
— HPING2 beta 54 от antirez ( http://sourceforge.net/projects/hping2 )
— Nemesis v1.1 от obecian (http://www.packetfactory.net/Projects/Nemesis) (http://www.packetninja.net/nemesis/)
— Icmpenum v1.1.1, от Simple Nomad (http://razor.bindview.com)
— SING v1.0 от Alfredo Andres Omella ( http://www.sourceforge.net/projects/sing)
Тип ICMP-сообщения, который мы будем определять во всех утилитах — ICMP Echo. Все утилиты в примерах будут выполняться под RedHat Linux, кernel 2.2.14.Запрос ICMP Echo
RFC 792 — Internet Control Message Protocol (http://www.ietf.org/rfc/rfc0792.txt ) — определяет способы посылки запросов ICMP Echo. Посылающая сторона инициализирует идентификатор (он используется для уникальной идентификации еcho-запросов) и sequence number (в случае если один хост параллельно пингуется несколькими пакетами), кроме того в в поле данных пакета добавляются некоторые данные ( вообще говоря, произвольные), далее пакет отправляется на конкретный хост. Хосту-получателю необходимо только изменить тип датаграммы на Echo reply и вернуть ее отсылавшему ее хосту (а также контрольную сумму ICMP-заголовка).Различия между утилитами
Тип Запросов Echo, которые использует утилита Linux ping.
Ниже приводится результат запроса Echo, который генерирует утилита ping из набора iputils (Redhat Linux based on Kernel 2.2.14):[root@godfather sbin]# ping -c 2 y.y.y.y PING y.y.y.y (y.y.y.y) from x.x.x.x : 56(84) bytes of data. 64 bytes from hostname (y.y.y.y): icmp_seq=0 ttl=255 time=0.1 ms 64 bytes from hostname (y.y.y.y): icmp_seq=1 ttl=255 time=0.1 ms --- y.y.y.y ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.1/0.1/0.1 ms [root@godfather sbin]#
Дамп, который выдает снифер snort:
11/01-23:09:51.398772 x.x.x.x —> y.y.y.y ICMP TTL:64 TOS:0x0 ID:38 ID:1037 Seq:0 ECHO 9F 86 00 3A 85 15 06 00 08 09 0A 0B 0C 0D 0E 0F . 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F . 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F !"#$%&'()*+,-./ 30 31 32 33 34 35 36 37 01234567 11/01-23:09:51.398819 y.y.y.y -> x.x.x.x ICMP TTL:255 TOS:0x0 ID:39 ID:1037 Seq:0 ECHO REPLY 9F 86 00 3A 85 15 06 00 08 09 0A 0B 0C 0D 0E 0F . 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F . 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F !"#$%&'()*+,-./ 30 31 32 33 34 35 36 37 01234567
Ниже приведен посылаемый ICMP запрос:
11/01-23:09:52.391176 x.x.x.x —> y.y.y.y ICMP TTL:64 TOS:0x0 ID:40 ID:1037 Seq:1 ECHO A0 86 00 3A EB F7 05 00 08 09 0A 0B 0C 0D 0E 0F . 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F . 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F !"#$%&'()*+,-./ 30 31 32 33 34 35 36 37 01234567 11/01-23:09:52.391220 y.y.y.y -—> x.x.x.x ICMP TTL:255 TOS:0x0 ID:41 ID:1037 Seq:1 ECHO REPLY A0 86 00 3A EB F7 05 00 08 09 0A 0B 0C 0D 0E 0F . 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F . 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F !"#$%&'()*+,-./ 30 31 32 33 34 35 36 37 01234567
Необходимо помнить несколько важных фактов, которые используются для идентификации ОС. Ping (также как другие утилиты в unix) использует поле данных длиной 56 байт, поэтому общая длина IP-датаграммы составляет 84 байта. Начальное значение ICMP sequence number — 0 и приращение берется равным единице. Ping использует по умолчанию 64 в качестве значения для поля TTL в запросе ICMP echo.
Кроме того, следует учитывать то, как определяются значения IP ID. Трассировка использовалась непосредственно после загрузки системы. Первое значение IP ID, которое было использовано — двузначное десятичное число. Приращение — 1. ICMP ID утилиты ping определяется равным ID процесса, который порождается во время запуска ping.HPING2
Утилита HPING2 позволяет генерировать специальные ICMP пакеты и просматривать ответы пингуемого хоста в стиле обычного утилиты ping. HPING2 поддерживает фрагментацию, позволяет определять размер и содержимое тела пакета и может использоваться для передачи файлов по поддерживаемым протоколам(для Linux и *BSD).
Далее приведет пример echo запроса, генерируемого HPING2:— [root@godfather sbin]# hping2 -1 -c 2 y.y.y.y — default routing not present — HPING y.y.y.y (y.y.y.y): icmp mode set, 28 headers + 0 data bytes — 28 bytes from y.y.y.y: icmp_seq=0 ttl=255 rtt=0.8 ms — 28 bytes from y.y.y.y: icmp_seq=1 ttl=255 rtt=0.7 ms --- y.y.y.y hping statistic --- 2 packets tramitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.7/0.7/0.8 ms [root@godfather sbin]#
Соответственно дамп снифера snort:
By Martin Roesch (roesch@clark.net, www.snort.org)11/01-23:08:48.338644 x.x.x.x -> y.y.y.y ICMP TTL:64 TOS:0x0 ID:14546 ID:1032 Seq:0 ECHO 11/01-23:08:48.338691 y.y.y.y -> x.x.x.x ICMP TTL:255 TOS:0x0 ID:36 ID:1032 Seq:0 ECHO REPLY
Обратите внимание на тот факт, что в теле пакета echo-запроса, генерируемого HPING2, по умолчанию не содержится данных. По умолчанию общий размер пакета — 28 байт. Как и обычный ping, HPING2 использует ID своего процесса в качестве значения поля ICMP ID.
[root@godfather /root]# ps aux | grep hping root 4826 0.0 0.4 1200 512 pts/1 S 19:57 0:00 [root@godfather /root]# 11/04-19:57:44.846703 x.x.x.x -> y.y.y.y ICMP TTL:64 TOS:0x0 ID:57750 ID:4826 Seq:20 ECHO In the sendicmp.c the program states: icmp ->un.echo.id = getpid();
Выше был приведен только первый запрос ICMP echo. Как же будет выглядеть второй?
11/01-23:08:49.331187 x.x.x.x -> y.y.y.y ICMP TTL:64 TOS:0x0 ID:19756 ID:1032 Seq:1 ECHO 11/01-23:08:49.331233 y.y.y.y —> x.x.x.x ICMP TTL:255 TOS:0x0 ID:37 ID:1032 Seq:1 ECHO REPLY 23:08:49.331187 > x.x.x.x > y.y.y.y: icmp: echo request (ttl 64, id 19756) 4500 001c 4d2c 0000 4001 2fb3 xxxx xxxx yyyy yyyy 0800 eefb 0804 0100
Сравнивая первую пару ICMP echo пакетов запрос-ответ со второй парой можно заметить, что они не идентичны. Различие присутствует по следующим параметрам:
— различные идентификационные номера в IP пакетах;
— используемые sequence numbers и их приращение относительно друг друга;
— контрольная сумма ICMP заголовка (изменяется поскольку меняется sequence number).
Можно также сделать вывод, что значение поля IP ID не синхронизируется с ID процесса ОС. В приведенных выше примерах, HPING2 использует для IP ID значения 14546 и 19756, в то время как ОС, соответствено, — 36 и 37 ( это легко проверить на локальной системе через loopback и убедиться, что значение IP ID вычисляется случайно)
Таким образом действительно полезный факт, касающийся HPING2, тот, что поле данных имеет нулевой размер.Nemesis
Nemesis — набор утилит для генерации пакетов TCP/UDP/ICMP/ARP/DNS/RIP/IGMP/OSPF с заданными свойствами (Linux , xBSD, Solaris).
Соответственно приводится запрос ICMP echo, который генерируется одной из утилит набора. Дополнительно используются опции -vv (verbose mode — дополнительная информация ) , -с (ICMP code value — значение, которым будет забиваться поле данных)
[root@godfather /root]# nemesis-icmp -vv -i 8 -c 0 -S x.x.x.x -D y.y.y.yICMP Packet Injection -=- The NEMESIS Project 1.1(c) 1999, 2000 obecian
[IP] x.x.x.x > y.y.y.y [Type] ECHO REQUEST [Sequence number] 0 [IP ID] 0 [IP TTL] 254 [IP TOS] 0x18 [IP Frag] 0x4000 Wrote 48 bytes
ICMP пакет сгенерирован. Трассировка, полученная с помощью tcpdump:
00:27:16.153322 > x.x.x.x > y.y.y.y: icmp: echo request (DF) [tos 0x18] (ttl 254, id 29) 4518 0030 001d 4000 fe01 7e95 xxxx xxxx yyyy yyyy 0800 f7ff 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00:27:16.153375 > y.y.y.y > x.x.x.x: icmp: echo reply [tos 0x18] (ttl 255, id 30) 4518 0030 001e 0000 ff01 bd94 yyyy yyyy xxxx xxxx 0000 ffff 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Интересующая нас информация, которую можно испльзовать для идентифицикации Nemesis:
• значение поля TOS(type of service) установлено в 0x18(по умолчанию долно использоваться 0x00);
• бит DF;
• значение поля TTL — 254 (ОС, кторую мы используетм в нашем случае, использует по умолчанию значение 64 для пакетов ICMP echo);
• значение поля идентификатора ICMP равно нулю (ICMP_ID=0);
• значение поля ICMP Sequence Number равно нулю (ICMP_Seq=0);
• объем поля данных равен 20 байтам (в то время как Linux и другие unix клоны используют 56 байт, а Microsoft Windows — соответствено 32). Это означает, что по умолчанию, длина датаграммы, которую генерирует Nemesis для запросов ICMP echo, — 48 байт. Все 20 байт поля данных равны нулю.Далее приведена вторая пара запросов ICMP echo:
00:27:23.294060 > x.x.x.x > y.y.y.y: icmp: echo request (DF) [tos 0x18] (ttl 254, id 31) 4518 0030 001f 4000 fe01 7e93 xxxx xxxx yyyy yyyy 0800 f7ff 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00:27:23.294097 > y.y.y.y > x.x.x.x: icmp: echo reply [tos 0x18] (ttl 255, id 32) 4518 0030 0020 0000 ff01 bd92 yyyy yyyy xxxx xxxx 0000 ffff 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Как можно заметить, вторая пара идентична первой за исключением значения идентификатора IP (который используется самой ОС) Контрольная сумма ICMP заголовка одинакова в обоих случаях, поскольку ICMP sequence number и идентификатор ICMP одни и те же.
Obecian обещает скоро выпустить новую версию (v2.0) Nemesis, в которой существенно расширятся возможности создания специфических пакетов.Icmpenum
Icmpenum — демонстрационая утилита, написанная Simple Nomad. С ее помощью можно генерировать основные типы ICMP запросов: Echo, TimeStamp, Information.[root@godfather /root]# ./icmpenum -i 1 IP_Address 11/04-19:40:22.256600 x.x.x.x -> y.y.y.y ICMP TTL:255 TOS:0x0 ID:666 ID:39426 Seq:0 ECHO 11/04-19:40:22.256662 y.y.y.y -> x.x.x.x ICMP TTL:255 TOS:0x0 ID:18 ID:39426 Seq:0 ECHO REPLY 19:40:22.256600 > x.x.x.x > y.y.y.y: icmp: echo request (ttl 255, id 666) 4500 001c 029a 0000 ff01 bb44 xxxx xxxx yyyy yyyy 0800 f565 029a 0000
Таким образом, можно сделать вывод, что размер генерируемого пакета всегда равен 28 байтам, причем поле данных — пустое. Сделаем другой запрос ICMP echo:
11/04-19:40:43.826947 x.x.x.x -> y.y.y.y ICMP TTL:255 TOS:0x0 ID:666 ID:39426 Seq:0 ECHO 11/04-19:40:43.826992 y.y.y.y -> x.x.x.x ICMP TTL:255 TOS:0x0 ID:19 ID:39426 Seq:0 ECHO REPLY
Значение IP ID всегда равно 0х029a (десятичное 666). ICMP sequence number всегда равен 0. IP TTL — 255. Таким образом, уже этих данных достаточно для идентификации icmpenum.
SING (Send ICMP Nasty Garbage)
SING — «швейцарский нож» ICMP. Данная утилита позволяет очень гибко определять параметры пакетов протокола ICMP (Linux, *BSD, Solaris). Вот пример отработки запроса ICMP :[root@godfather /root]# sing -c 4 y.y.y.y SINGing to y.y.y.y (y.y.y.y): 16 data bytes 16 bytes from y.y.y.y: seq=0 ttl=255 TOS=0 time=0.169 ms 16 bytes from y.y.y.y: seq=1 ttl=255 TOS=0 time=0.155 ms 16 bytes from y.y.y.y: seq=2 ttl=255 TOS=0 time=0.136 ms 16 bytes from y.y.y.y: seq=3 ttl=255 TOS=0 time=0.136 ms --- y.y.y.y sing statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.136/0.149/0.169 ms [root@godfather /root]#
А вот дамп поступающих пакетов:
00:24:59.011868 > x.x.x.x > y.y.y.y: icmp: echo request (ttl 255, id 13170) 4500 0024 3372 0000 ff01 8a64 xxxx xxxx yyyy yyyy 0800 7cad 3c04 0000 2be6 e039 332e 0000 00:24:59.011908 > y.y.y.y > x.x.x.x: icmp: echo reply (ttl 255, id 25) 4500 0024 0019 0000 ff01 bdbd yyyy yyyy xxxx xxxx 0000 84ad 3c04 0000 2be6 e039 332e 0000
Следующая информация может использоваться для идентификации SING.
• IP TTL — 255 (для нашей Linux по умолчанию IP TTL равно 64)
• идентификатор ICMP — 0x3c04( 1084). ICMP ID равен значению ID процесса SING
• используются только 8 байт в поле данных, они в свою очередь используются для вычисления RTT. Следовательно, общая длина датаграммы с ICMP echo — 36 байт.
Трассировка tcpdump второй пары пакетов запрос-ответ:00:25:00.004593 > x.x.x.x > y.y.y.y: icmp: echo request (ttl 255, id 13170) 4500 0024 3372 0000 ff01 8a64 xxxx xxxx yyyy yyyy 0800 d6c9 3c04 0100 2ce6 e039 d711 0000 00:25:00.004630 > y.y.y.y > x.x.x.x: icmp: echo reply (ttl 255, id 26) 4500 0024 001a 0000 ff01 bdbc yyyy yyyy xxxx xxxx 0000 dec9 3c04 0100 2ce6 e039 d711 0000
Вторая пара запросов ICMP Echo позволяет сделать вывод, что:
• значение IP ID используется одно и тоже;
• sequence number отличаются (приращение остается равным единице), поэтому контрольная сумма ICMP заголовка различна.Способы идентификации ОС, на которой выполнялась утилита (на примере SING)
Если вы не хотите углубляться в исходные тексты, тогда необходимо учесть несколько фактов, которые помогут проидентифицировать ОС, на которой выполнялись разновидности утилиты ping. Рассмотрим эти факты на примере SING. Когда SING запускается из под Linux или xBSD, то она использует в качестве IP ID константу 0x3372. В данном случае исключение составляет Solaris, поскольку эта ОС не позволяет определять IP ID для пакета. Таким образом существует простой способ идентифицикации SING, когда она выполняется на Solaris.
Кроме того, можно использовать тот факт, что по умолчанию Solaris устанавливает в запросе ICMP бит DF (и в данном случае SING не исключение).
Значение поля ICMP ID определяется ID процесса SING в конкретной ОС. Если мы сможем для разных ОС примерно представить диапазон значений выделяемых процессу SING, то это также приблизит нас к решению поставленной задачи. Например, в Linux непосредственно после загрузки значение ICMP ID равно 3c04, FreeBSD cоответственно — 1b03 и Solaris — 7330 hex.Другие типы запросов ICMP
Мы рассмотрели только один вид запросов ICMP — echo. Если принять во внимание другие типы , то это позволит дополнительно повысить точность идентификации конкретной используемой утилиты, но при этом необходимо учитывать, что echo — это единственный тип ICMP-сообщений, который поддерживают практически все ОС.Различные опции в различных утилитах
Иногда, просматривая дамп трассировки ICMP датаграм, можно определенно слелать вывод, что значение для какого-либо поля было специально подобрано. Можно ли на основе этого идентифицировать используемую утилиту?
В большинстве случаев — да. При этом неважно, какой конкретно тип ICMP-запроса используется, поскольку манипуляции со значениями полей остаются специфичными для каждой конкретной утилиты.Мимикрия под различные ОС
Единственная утилита, обладающая данной способностью, которую я видел, — это SING.Шаблоны снифера snort
Далее приводятся шаблоны snort для идентификации описанных в данной статье утилит. Использоване поля TOS добавлено в последней версии snort( при этом бит DF до сих пор не учитывается):alert icmp !$HOME_NET any -> $HOME_NET any (msg:"SING Echo from LINUX/*BSD"; id:13170; itype: 8; dsize: 8;) alert icmp !$HOME_NET any -> $HOME_NET any (msg:"SING Echo from Sun Solaris"; itype: 8; dsize: 8;) alert icmp !$HOME_NET any -> $HOME_NET any (msg:"Nemesis v1.1 Echo"; content:"|0000000000000000000000000000000000000000|"; itype: 8;icmp_id: 0; icmp_seq: 0; dsize: 20;) alert icmp !$HOME_NET any -> $HOME_NET any (msg:"icmpenum v1.1.1"; id: 666; itype: 8;icmp_id: 666; icmp_seq: 0; dsize: 0;) alert icmp !$HOME_NET any -> $HOME_NET any (msg:"HPING2 Echo from LINUX/*BSD"; itype: 8; dsize:0;)
Информация данной статьи впервые была представлена на конференции Black Hat 2000 Amsterdam, 23-25 октября 2000 и доступна на сайте Black Hat:http://www.blackhat.com
Сетевые решения. Статья была опубликована в номере 01 за 2001 год в рубрике технологии
Что такое ICMP?
Протокол Internet Control Message Protocol (ICMP) – это набор коммуникационных правил, которые устройства используют для распространения информации об ошибках передачи данных в сети. При обмене сообщениями между отправителем и получателем могут возникнуть непредвиденные ошибки. Например, сообщения могут быть слишком длинными или пакеты данных могут приходить не по порядку, поэтому получатель не может их организовать. В таких случаях получатель использует ICMP для информирования отправителя сообщением об ошибке и просит отправить сообщение повторно.
Какие существуют варианты использования ICMP?
Протокол Internet Control Message Protocol (ICMP) является важным протоколом сетевого уровня в компьютерных сетях. Он обеспечивает стандартизированный механизм передачи сетевыми устройствами важной информации, такой как подключение и состояние сети. Все устройства, подключенные к сети, включая маршрутизаторы и конечные устройства, могут обрабатывать сообщения ICMP. ICMP адаптирован для работы как с IPv4, так и с IPv6.
Далее мы обсудим некоторые распространенные варианты использования ICMP.
Отчеты об ошибках
Сообщения об ошибках ICMP информируют о сетевых ошибках – например, о недоступных местах назначения, тайм-аутах или проблемах фрагментации. Сообщения особенно важны для протокола пользовательских дейтаграмм (UDP), который использует модель коммуникации без подключения.
UDP не обеспечивает надежную упорядоченную доставку пакетов. При отправке пакета UDP существует вероятность, что пакет может быть утерян или доставлен с ошибками, например с ошибками контрольной суммы. Если это происходит, получатель отправляет сообщения об ошибках ICMP отправителю, чтобы уведомить его о проблеме.
Диагностика
ICMP можно использовать для диагностики сети. Чаще всего он используется для команд ping и traceroute.
Команда ping проверяет доступность сетевых устройств, отправляя пакеты эхо-запроса ICMP на целевое устройство. Если устройство доступно, оно возвращает эхо-ответ ICMP. Благодаря этому надежно проверяется задержка в сети и обеспечивается доступность устройства.
Команда traceroute отслеживает путь пакетов от источника до места назначения. Для этого команда отправляет сообщения эхо-запроса и эхо-ответа в указанное место назначения.
Эхо-запросы содержат значение времени жизни (TTL), которое уменьшается на единицу при каждом прохождении пакета через маршрутизатор. Когда пакет достигает маршрутизатора с нулевым значением TTL, маршрутизатор отправляет сообщение ICMP обратно источнику.
В сообщении содержится информация о маршруте, пройденном пакетом. С помощью команды Traceroute можно узнать точный путь пакета, чтобы получить представление о производительности сети.
сетевая безопасность;
ICMP можно использовать для обнаружения несанкционированного сетевого трафика и разрешать только законный трафик в сети. Брандмауэры используют ICMP для разрешения или блокировки определенных типов трафика. Сетевые администраторы также используют инструменты мониторинга ICMP для отслеживания состояния и подключения сетевых устройств, а также обнаружения неизвестных устройств.
Вы также можете использовать протокол для выявления необычных схем трафика, которые могут указывать на несанкционированную активность.
Как работает ICMP?
Протокол Internet Control Message Protocol (ICMP) обычно работает вместе с другими сетевыми протоколами, например TCP/IP или протоколом пользовательских дейтаграмм (UDP). Хосты и маршрутизаторы обмениваются сообщениями или пакетами ICMP при возникновении определенных сетевых событий.
Пакет ICMP состоит из заголовка пакета ICMP и раздела данных ICMP.
Заголовок пакета ICMP
Заголовок ICMP содержит информацию о типе пакета, его коде, контрольной сумме и идентификаторе. При отправке пакетов ICMP получатель сообщения считывает информацию в заголовке и в зависимости от типа пакета принимает соответствующие меры.
Например, если используется эхо-запрос, получатель отправляет эхо-ответ с теми же данными. Если тип – недоступное место назначения, получатель отвечает сообщением, в котором указано, что оно недоступно.
Раздел данных ICMP
Раздел данных в сообщении ICMP содержит такую информацию, как IP-адрес получателя или причина сбоя, а также коды ошибок или числовые коды, идентифицирующие ошибки.
Ниже приведены некоторые примеры.
- Код недоступного места назначения (тип 3) означает, что устройство получателя не существует в сети
- Код перенаправления (тип 5) отправляет сообщение другому маршрутизатору с указанием лучшего маршрута к месту назначения
- Коды эхо-запроса и эхо-ответа (типы 8 и 10) проверяют связь между устройствами
- Сообщение о превышении времени показывает, что пакет достиг места назначения
- Сообщение Parameter Problem (Проблема параметра) указывает, что маршрутизатор столкнулся с проблемой в заголовке поля IP
- Сообщение Source Quench (Подавление источника) отправляется, когда маршрутизатору приходится сталкиваться с перегрузкой и ему необходимо ограничить количество получаемых пакетов
В чем разница между ICMP и TCP?
TCP – это ориентированный на соединение протокол для надежной доставки данных с проверкой на ошибки. Он обычно используется для просмотра веб-страниц, электронной почты, удаленного входа в систему и приложений для передачи файлов. TCP требует передачи данных (handshaking) – серии сообщений, которые обеспечивают доверие и проверку личности между отправителем и получателем. TCP гарантирует доставку сообщений.
Напротив, протокол Internet Control Message Protocol (ICMP) – это протокол без подключения, который не гарантирует доставку сообщений. Поскольку ICMP используется только для отчетов об ошибках, сообщения ICMP также меньше пакетов TCP.
ICMP и TCP используются совместно для определения причины сбоя доставки по протоколу TCP.
Что такое наплыв пингов ICMP?
Наплыв пингов по протоколу Internet Control Message Protocol (ICMP) – это события типа «отказ в обслуживании» (DoS), когда неавторизованные пользователи отправляют несколько эхо-запросов ICMP за короткий период времени. В каждом запросе ICMP содержится уникальный идентификатор и полезная нагрузка данных, которая требует от получателя уникального ответа. Принимающий сервер пытается ответить на каждый несанкционированный запрос, в результате чего ответы авторизованных источников задерживаются или замедляются.
Для защиты от наплыва пингов ICMP следует убедиться, что устройства вашей сети настроены на ограничение объема трафика ICMP, который они готовы принять. Также важно контролировать свою сеть на предмет несанкционированной активности и применять необходимые меры безопасности, например использовать брандмауэры и системы обнаружения вторжений (IDS).
Как AWS может усилить защиту от DDoS-событий?
Amazon Web Services (AWS) предлагает сервис AWS Shield, чтобы улучшить защиту от событий типа «распределенный отказ в обслуживании» (DDoS).
AWS Shield — это управляемый сервис защиты от DDoS-атак, который надежно защищает приложения, работающие в облаке AWS. Он обеспечивает динамическое обнаружение и автоматические встроенные средства защиты, которые минимизируют время простоя и задержки приложений. В AWS Shield предусмотрены автоматизированные методы нейтрализации угроз для защиты от всех типов событий сетевой безопасности.
AWS Shield предоставляет вам множество возможностей.
- Автоматическая очистка несанкционированного трафика на определенных уровнях
- Минимизация времени простоя и задержек приложений
- Мониторинг и защита до 1000 типов ресурсов
- Индивидуальное обнаружение на основе шаблона трафика приложения
Начните использовать защиту от DDoS-событий, создав аккаунт сегодня.