Здравствуйте. А уточните, пожалуйста, по какой причине стоимость изменилась? Была стоимость в 1 рубль, стала в 9900 рублей. |
Анализ сетевого трафика как метод диагностики сети
Ключевые термины
Беспорядочный (promiscuous) режим — режим работы сетевого адаптера, при котором принимаются все фреймы, а не те, которые предназначены данному узлу, как в обычном состоянии.
Сетевой монитор или анализатор (sniffer) — средство для перехвата и анализа сетевого трафика.
Краткие итоги
- Для анализа трафика узла (а также для анализа трафика сетевого сегмента) можно использовать специальные средства — сетевые анализаторы или мониторы.
- В Unix-подобных ОС утилита tcpdump позволяет выполнять базовые операции по перехвату сетевого трафика, декодирования протоколов, записи и чтения сетевого трафика в файл, фильтрации трафика для анализа и т. д.
- Для анализа трафика в графическом режиме пользователя можно использовать пакет wireshark.
Упражнения
1.В среде VirtualBox запустите виртуальную машину (ВМ) с установленным Debian GNU\Linux и установленным HTTP-сервером с одной сетевой картой, предварительно установив тип сетевого подключения "Виртуальная сеть узла" .
Изучите процесс взаимодействия между HTTP-сервером, установленным на ВМ, и клиентом на основной системе:
1.1.Запустите на консоле ВМ утилиту tcpdump c параметрами -nve.
1.2.В основной системе запустите командный интерпретатор и используя утилиту telnet установите TCP соединение с HTTP-сервером, слушающим на 80 порту ВМ:
# telnet <IP-адрес ВМ> 80
Затем отправьте ВМ запрос корневой страницы, закончив ввод двойным нажатием клавиши enter:
GET / HTTP/1.1 Host: <IP-адрес ВМ>
Сервер должен выдать ответ с кодом 200 (HTTP/1.1 200 OK)
1.3.Переключитесь в ВМ и, используя результаты работы tcpdump, последовательно изучите ход сетевого соединения.
2.Для данного упражнения необходимо, чтобы в виртуальной машине с установленным Debian GNU\Linux были установлены HTTP и SSH-сервера. Сетевая карта виртуальной машины должна быть подключена к виртуальной сети узла VirtualBox.
2.1.Запустите на консоли виртуальной машины tcpdump таким образом, чтобы перехваченные пакеты в низкоуровневом формате записывались в файл (дамп трафика). Далее:
- Проверьте доступность виртуальной машины с основной с помощью ping.
- Проверьте доступность основной системы с виртуальной с помощью ping.
- Запустите Интернет-обозреватель в основной системе и запросите страницу с HTTP-сервера виртуальной машины.
- Затем, используя клиент ssh (для Windows можно использовать putty или winscp ), подключитесь с основной системы к виртуальной машине и отключитесь).
- Используя утилиту telnet, попробуйте подключиться с основной системы к виртуальной машине на порт 8080.
- Попробуйте с виртуальной машины сделать DNS-запрос на разрешение имени http://www.yandex.ru, используя утилиту nslookup (apt-get install dnsutils).
- Удалите из ARP-таблицы виртуальной машины запись о MAC-адресе основной системы, а затем проверьте доступность основной системы с помощью ping.
Затем прервите работу tcpdump комбинацией клавиш Ctrl+C.
2.2.Сконструируйте правила tcpdump, которые бы из полученного файла дампа отображали:
2.2.2.ICMP-пакеты, отправленные основной системой
2.2.3.Взаимодействие по протоколу TCP между основной системой и виртуальной машиной.
2.2.4.Взаимодействие между HTTP-клиентом и HTTP-сервером.
2.2.5.Взаимодействие между основной системой и TCP-портом 8080 виртуальной машины. Было ли это взаимодействие удачным?
2.2.6.Отобразите весь UDP-трафик, который присутствует в файле дампа.
2.2.7.Отобразите широковещательный трафик (с информацией уровня доступа к сети), который находится в файле дампа.
2.2.8.Отобразите ARP-трафик, который содержится в дампе (с информацией уровня доступа к сети).
3. В локальном сегменте сети (подсеть 192.168.6.0/24) сетевые станции не могут взаимодействовать друг с другом по протоколу IP. Изучить фрагмент вывода tcpdump и объяснить причину данной ситуации:
$ tcpdump -ne -r ex3.dump reading from file ex3.dump, link-type EN10MB (Ethernet) 16:20:38.558302 00:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.30 tell 192.168.6.5, length 28 16:20:38.580672 00:00:00:00:00:03 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 192.168.6.30 is-at 00:00:00:00:00:03, length 28 16:20:38.639393 00:00:00:00:00:01 > 00:00:00:00:00:03, ethertype IPv4 (0x0800), length 42: 192.168.6.5 > 192.168.6.30: ICMP echo request, id 33887, seq 13729, length 8 16:20:38.654419 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 192.168.6.30 is-at 00:00:00:00:00:02, length 28 16:20:38.683649 00:00:00:00:00:01 > 00:00:00:00:00:03, ethertype IPv4 (0x0800), length 42: 192.168.6.5 > 192.168.6.30: ICMP echo request, id 5362, seq 61839, length 8 16:20:38.709642 00:00:00:00:00:04 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.10 tell 192.168.6.4, length 28 16:20:38.729719 00:00:00:00:00:05 > 00:00:00:00:00:04, ethertype ARP (0x0806), length 42: Reply 192.168.6.10 is-at 00:00:00:00:00:05, length 28 16:20:38.748087 00:00:00:00:00:01 > 00:00:00:00:00:03, ethertype IPv4 (0x0800), length 42: 192.168.6.5 > 192.168.6.30: ICMP echo request, id 4309, seq 56734, length 8 16:20:38.770256 00:00:00:00:00:03 > 00:00:00:00:00:04, ethertype ARP (0x0806), length 42: Reply 192.168.6.10 is-at 00:00:00:00:00:03, length 28 16:20:38.803840 00:00:00:00:00:01 > 00:00:00:00:00:03, ethertype IPv4 (0x0800), length 42: 192.168.6.5 > 192.168.6.30: ICMP echo request, id 46657, seq 6367, length 8 16:20:38.829548 00:00:00:00:00:04 > 00:00:00:00:00:05, ethertype IPv4 (0x0800), length 42: 192.168.6.4 > 192.168.6.10: ICMP echo request, id 6239, seq 43338, length 8 16:20:38.861968 00:00:00:00:00:05 > 00:00:00:00:00:04, ethertype IPv4 (0x0800), length 42: 192.168.6.10 > 192.168.6.4: ICMP echo reply, id 0, seq 0, length 8 16:20:38.885832 00:00:00:00:00:06 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.20 tell 192.168.6.21, length 28 16:20:38.914436 00:00:00:00:00:03 > 00:00:00:00:00:06, ethertype ARP (0x0806), length 42: Reply 192.168.6.20 is-at 00:00:00:00:00:03, length 28 16:20:38.953113 00:00:00:00:00:04 > 00:00:00:00:00:05, ethertype IPv4 (0x0800), length 42: 192.168.6.4 > 192.168.6.10: ICMP echo request, id 41141, seq 12273, length 8 16:20:38.978185 00:00:00:00:00:10 > 00:00:00:00:00:06, ethertype ARP (0x0806), length 42: Reply 192.168.6.20 is-at 00:00:00:00:00:10, length 28 16:20:39.018692 00:00:00:00:00:01 > 00:00:00:00:00:03, ethertype IPv4 (0x0800), length 42: 192.168.6.5 > 192.168.6.30: ICMP echo request, id 15440, seq 26713, length 8 16:20:39.037768 00:00:00:00:00:05 > 00:00:00:00:00:04, ethertype IPv4 (0x0800), length 42: 192.168.6.10 > 192.168.6.4: ICMP echo reply, id 0, seq 0, length 8 16:20:39.073481 00:00:00:00:00:01 > 00:00:00:00:00:03, ethertype IPv4 (0x0800), length 42: 192.168.6.5 > 192.168.6.30: ICMP echo request, id 1117, seq 65455, length 8 16:20:39.197000 00:00:00:00:00:06 > 00:00:00:00:00:03, ethertype IPv4 (0x0800), length 70: 192.168.6.21.21519 > 192.168.6.20.53: 28042 A? www.tut.by. (28) 16:20:39.252522 00:00:00:00:00:1a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.20 tell 192.168.6.100, length 28 16:20:39.270199 00:00:00:00:00:03 > 00:00:00:00:00:1a, ethertype ARP (0x0806), length 42: Reply 192.168.6.20 is-at 00:00:00:00:00:03, length 28 16:20:39.293142 00:00:00:00:00:10 > 00:00:00:00:00:1a, ethertype ARP (0x0806), length 42: Reply 192.168.6.20 is-at 00:00:00:00:00:10, length 28 16:20:39.408039 00:00:00:00:00:1a > 00:00:00:00:00:03, ethertype IPv4 (0x0800), length 72: 192.168.6.100.21455 > 192.168.6.20.53: 29961 A? www.aport.ru. (30) 16:20:39.546045 00:00:00:00:00:06 > 00:00:00:00:00:03, ethertype IPv4 (0x0800), length 70: 192.168.6.21.55962 > 192.168.6.20.53: 64123 A? www.tut.by. (28) 16:20:39.685004 00:00:00:00:00:1a > 00:00:00:00:00:03, ethertype IPv4 (0x0800), length 72: 192.168.6.100.30522 > 192.168.6.20.53: 41887 A? www.aport.ru. (30)