Салимóненко Дмитрий Александрович

Вычислительные Сети, Системы и Телекоммуникации

ЗАДАНИЕ 1: Основы работы с сетью в LINUX при помощи утилит




Введение


В этом задании Вы потренируетесь работать с сетью в Linux. А именно – сканировать сеть, т.е.:

  • определять порты, открытые для прослушивания,
  • определять протоколы, используемые компьютером (локальным или удаленным) в данный момент.

Обращаем внимание: при помощи некоторых из обсуждаемых ниже утилит возможно исследовать сетевые особенности не только своего локального (т.е. того, на котором работаете Вы), но и удаленного компьютера, т.е. сервера в сети интернет. Последний может быть задан либо по доменному имени, либо по IP-адресу.

Возможности утилит являются достаточно широкими. Например, вполне можно выявить несанкционированные соединения, установленные без Вашего ведома (или без ведома программы, которой Вы разрешили это сделать).

Примечание 1. Некоторые сетевые возможности в Linux приведены в Заданиях 2, 3, которые реализованы в соответствующих программах. Однако, функционал тех программ является, конечно, достаточно ограниченным и будет реализован, в основном, лишь в учебных целях. Здесь же Вы увидите и попробуете «вживую» гораздо больше возможностей.

Примечание 2. Сетевые утилиты применительно к удаленным компьютерам (серверам) используйте ОЧЕНЬ аккуратно. Не секрет, что при помощи них можно реализовать так называемую DDoS-атаку. Собственно, примерно таким образом она и, нередко, реализуется на практике. НО: делать этого НЕ нужно. Во-первых, это нехорошо, как минимум. Во-вторых, Вас вполне могут вычислить по IP-адресу и/или местоположению (даже если Вы будете использовать прокси-серверы) и все дело может закончиться реальным уголовным сроком. Все-таки, университетские навыки, умения и познания должны приобретаться студентами отнюдь не для этого, не так ли?


Утилита nmap

↑ К содержанию ↑

Это – пожалуй, наиболее широко известная утилита в мире профессионалов, обслуживающих серверы Linux. В стандартные дистрибутивы Linux она, как правило, не входит, потому устанавливать ее необходимо самостоятельно. Естественно, для этого необходимы права администратора (суперпользователя).

Примечание. Для Windows также есть аналогичная утилита.

Архивы с утилитами можно скачать с официального сайта nmap.org. Там приведен довольно большой список версий. Я сам, к примеру, тестировал версию nmap-7.60.tgz от 2017-08-01, она имеет размер 12MБ.

В принципе, процесс установки этой утилиты очень хорошо описан здесь. На всякий случай, повторим здесь основные этапы.

Установка может производиться двумя путями:

1) Автоматическая установка:
sudo apt-get install nmap

(если Вы работаете в Ubuntu). ОС спросит пароль, после верного его ввода начнется установка.

Однако, может возникнуть проблема, если у Вас установлена старая версия Ubuntu. Дело в том, что релизы этой операционной системы меняются, вроде бы, каждые 9 месяцев. Соответственно, приведенная выше команда будет запрашивать версию nmap именно с тех адресов в интернете, которые соответствуют СТАРОЙ версии ОС. Однако, как правило, эти версии впоследствии переносятся в архив (что приводит к смене адреса). В итоге при попытке установки путем указанной команды Вы в консоли будете получать сообщения типа:

404  Not Found [IP: 91.189.91.26 80]
Err http://us.archive.ubuntu.com/ubuntu/ utopic/main nmap amd64 6.46-2ubuntu1

Подобные сообщения означают, что, скорее всего, по указанным адресам в архивах ничего полезного для нас нет (ошибка 404 означает. что соответствующая вебстраница недоступна). А это, в свою очередь, означает, что для того, чтобы воспользоваться данной командой, придется ВРУЧНУЮ (как и многое в Linux, увы) искать на официальном сервере Ubuntu необходимые нам архивы и, после чего, соответствующим образом конфигурировать команду.

Ну, или, как вариант – устанавливать самую последнюю версию ОС. Однако, если в процессе работы в Linux приходится периодически устанавливать то одни, то другие утилиты, модули, то из вышесказанного следует, что при этом придется, в среднем, 1-2 раза в год обновлять ОС. По поводу последнего я, теоретически, ничего не имею против. Однако, возникает резонный вопрос: а, собственно, работать-то в ОС – когда? Если постоянно/периодически приходится ее обновлять и, зачастую, заново устанавливать ранее инсталлированные утилиты? Это утомительно, да и время от времени придется вспоминать, как там что делалось.  Поэтому данный вариант, вероятно, будет не самым удобным.

2) Установка вручную:

а) wget -O Nmap.tgz http://nmap.org/dist/nmap-6.25.tgz

Это – команда, при помощи которой происходит скачивание утилиты версии 6.25. Обращаем внимание, что вместо этого можно самостоятельно посетить сайт nmap.org (ссылку см. выше) и скачать понравившуюся Вам версию утилиты оттуда вручную:
б) tar -xvzf Nmap.tgz

Это – команда разорхивации скачанного файла с утилитой. При этом автоматически создастся каталог с именем nmap-6.25. В него следует перейти при помощи следующей команды:
в) cd nmap-6.25

Переходим в нужный каталог:
г) ./configure

По всей видимости, это – команда что-то где-то конфигурирует. Делает она это долго, несколько минут. Следует дождаться удачного завершения.
д) make

Запускаем созданный make-файл. Это – тоже довольно длительный процесс, но и он когда-нибудь закончится.
е) sudo make install

И, наконец, в качестве завершающего этапа – запускаем саму команду инсталляции утилиты nmap. Еще немного ожидания – и утилита будет установлена в системе. По крайней мере, у меня в VMware Player, Linux Ubuntu 14.10 она установилась без особых проблем.

Для того, чтобы узнать информацию о работе этой команды, можно воспользоваться, как обычно, справочной системой:
man nmap

Предупреждаем, что содержание справки здесь составляет более 2000(!) строк. Возможности данной утилиты достаточно широки. Но, мы с Вами рассмотрим лишь некоторые из них – чтобы Вы получили представление о том, какие примерно виды задач она может решать.

Примечание. Не стоит вводить ПРОИЗВОЛЬНЫЙ IP-АДРЕС при использовании данной утилиты. В диапазон адресов могут попасть некие интересные учреждения, о которых в обычной жизни говорить вслух не принято. Даже сканирование (не говоря уже о пинговании) адресов, сетей таких учреждений может окончиться (в России) тюремным сроком. Раз уж даже за митинги или перепосты чужих сообщений людей сажают.

1) nmap scanme.nmap.org

Для примера, взят сервер - сайт разработчика утилиты: scanme.nmap.org. И вот результаты:

Starting Nmap 7.60 ( https://nmap.org ) at 2017-08-14 12:52 PDT
Stats: 0:00:03 elapsed; 0 hosts completed (1 up), 1 undergoing Connect Scan
Connect Scan Timing: About 2.15% done; ETC: 12:54 (0:02:17 remaining)
Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up (0.25s latency).
Other addresses for scanme.nmap.org (not scanned): 2600:3c01::f03c:­91ff:fe18:bb2f
Not shown: 990 filtered ports
PORT  STATE  SERVICE
22/tcp  open   ssh
80/tcp  open   http
110/tcp   closed pop3
111/tcp   closed rpcbind
199/tcp   closed smux
256/tcp   closed fw1-secureremote
995/tcp   closed pop3s
1025/tcp  closed NFS-or-IIS
5900/tcp  closed vnc
31337/tcp open   Elite
Nmap done: 1 IP address (1 host up) scanned in 35.34 seconds

Что видим? Программа показывает IP-адреса в двух форматах: IPv4 и IPv6. Показываются также открытые (open) и закрытые (closed) порты. Также сообщается, что есть 990 портов, которые заблокированы сервером. Т.е. о них информации утилита nmap получить не может.

Примечание. Интересно, что при повторном вызове утилиты для этого сайта выдаваемая информация гораздо скуднее и состоит всего из двух видов протоколов – SSH и HTTP. Возможно, сервер, обнаружив, что с нашего IP-адреса произошел повторный аналогичный запрос, перестал «затруднять себя», выдав только наиболее необходимые, по его мнению, порты.

Nmap распознаёт следующие состояния портов: open, filtered, closed, или unfiltered:

  1. Open означает, что приложение на целевой машине готово для принятия пакетов на этот порт.
  2. Filtered означает, что брандмауэр, фильтр, или что-то другое в сети блокирует порт, так что Nmap не может определить, является ли порт открытым или закрытым.
  3. Closed — не связаны в данный момент ни с каким приложением, но могут быть открыты в любой момент.
  4. Unfiltered порты отвечают на запросы Nmap, но нельзя определить, являются ли они открытыми или закрытыми.

Мы видим, что, скажем, для того, чтобы обратиться к данному серверу по протоколу SSH (например, при помощи интерфейса сокетов), необходимо указывать порт 22 для ТСР протокола (см. задания с сокетами по предмету Вычислительные Системы, Сети и Телекоммуникации). Напомним, что порт задается командой вида
addr.sin_port = htons(3425);

В данном случае, вместо 3425 будет фигурировать порт под номером 22.

Если же мы захотим обратиться к этому серверу по протоколу http, тогда порт нужно указать номер 80.

Примечание. Отметим, что это – стандартный порт, который является открытым на прослушивание в очень многих компьютерах-серверах, на которых расположены сайты. А вообще, номер порта может быть выбран администратором сервера произвольно – для любого протокола. Общеизвестный номер порта применятся для того, чтобы для программ, обращающихся к серверу, не было необходимости «угадывать» его или применять при обращении утилиты наподобие nmap.

Для проверки, Вы можете ввести любое другое (существующее!) доменное имя какого-нибудь сайта – и утилита выдаст информацию о портах для сервера, на котором физически находится этот сайт.

Таким образом, зная доменное имя, протокол и номер порта, соответствующий последнему, для конкретного сервера, можно послать ему запрос и получить ответ.

Вместо доменного имени можно ввести IP-адрес, например:
nmap 45.33.32.156

Результат будет тем же самым.

В локальной сети (состоящей из одного компьютера, подключенного через виртуальную машину и модем – к провайдеру) выдается сообщение следующего вида:
Nmap scan report for localhost (192.168.145.135)
Host is up (0.0000010s latency).
All 1000 scanned ports on localhost (192.168.145.135) are closed
Nmap done: 1 IP address (1 host up) scanned in 0.39 seconds

Подумайте, почему ВСЕ порты закрыты, почему ни одного протокола не показывает эта утилита? Попробуйте запустить один из листингов-серверов и запустите утилиту вновь – изменятся ли результаты ее работы для локальной сети?

Данная утилита позволяет применять многочисленные опции:

Сканирования протокола TCP SYN:
nmap -sS 192.168.145.135

Сканирования протокола UDP:
nmap -sU 192.168.145.135

Сканирование протокола IP:
nmap -sO 192.168.145.135

Сканирование выбранных портов (80, 25, 443):
nmap -p 80,25,443 192.168.145.135

Сканирование диапазона портов 1024-2048:
nmap -p 1024-2048 192.168.145.135

Обнаружение вида ОС:
nmap -O --osscan-guess 192.168.145.135

В локальных сетях или просто имея на руках диапазон ip адресов, удобно проверить их на занятость с помощью ключей –sP (с указанием маски):
nmap -sP 192.168.145.0/24

Ответ будет выглядеть так:
Starting Nmap 7.60 ( https://nmap.org ) at 2017-08-14 13:38 PDT
Nmap scan report for localhost (192.168.145.2)
Host is up (0.0070s latency).
Nmap scan report for localhost (192.168.145.135)
Host is up (0.00015s latency).
Nmap done: 256 IP addresses (2 hosts up) scanned in 2.68 seconds.

Таким образом, видим, что в локальной сети имеется 2 хоста. Времена ответов для них составляют, соответственно, 0,007 сек и 0,00015 сек.

Отметим, что в справочной системе по данной утилите, как уже говорилось, присутствуют и многие другие опции. Попробуйте поэкспериментировать самостоятельно, выбрав для себя 2…3 наиболее интересных, на Ваш взгляд, опций.

Более подробно работа утилиты nmap рассмотрена, например, в этой статье. Можете опробовать некоторые примеры из этой статьи.


Утилита ip a (ifconfig – аналог)

↑ К содержанию ↑

Эта утилита дает информацию о сетевых интерфейсах (аналогичные программы будут выполнены Вами в Задании 2). Вот примерный результат ее работы:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
  valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host
  valid_lft forever preferred_lft forever
2: eth0: <BROADCAST, MULTICAST, PROMISC,UP, LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
 link/ether 00:0c:29:fd:92:b9 brd ff:ff:ff:ff:ff:ff
 inet 192.168.145.135/24 brd 192.168.145.255 scope global eth0
  valid_lft forever preferred_lft forever
 inet6 fe80::20c:29ff:fefd:92b9/64 scope link
  valid_lft forever preferred_lft forever

Видим, что присутствуют два интерфейса: локальный (lo) и приватный (eth0).

Утилита ping

↑ К содержанию ↑

Данная утилита позволяет проверить доступность хостинга (сервера) по его IP-адресу или по доменному имени, замеряя время отклика сервера. Например:

  • Можно узнать IP-адрес по доменному имени.
  • Можно узнать, работает ли сервер. Например, системный администратор может узнать, завис ли только веб-сервер или проблемы с хостом.
  • Можно узнать, есть ли связь с сервером. Например, проблемы с настройкой DNS серверов на машине можно узнать, задав в ping сначала доменное имя, а потом IP-адрес.
  • Также можно узнать качество канала, посмотрев, сколько ответов не пришло.

Примечание. В Windows есть аналогичная утилита.

Вот  как ею пользоваться:

ping -w 5 45.33.32.156

или

ping -w 5  scanme.nmap.org

Вот что получится:

PING scanme.nmap.org (45.33.32.156) 56(84) bytes of data.
64 bytes from scanme.nmap.org (45.33.32.156): icmp_seq=1 ttl=128 time=262 ms
64 bytes from scanme.nmap.org (45.33.32.156): icmp_seq=2 ttl=128 time=234 ms
64 bytes from scanme.nmap.org (45.33.32.156): icmp_seq=3 ttl=128 time=243 ms
64 bytes from scanme.nmap.org (45.33.32.156): icmp_seq=4 ttl=128 time=238 ms
64 bytes from scanme.nmap.org (45.33.32.156): icmp_seq=5 ttl=128 time=242 ms
--- scanme.nmap.org ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 234.035/243.973/262.669/9.886 ms

Видим, что среднее время ответа сервера составляет примерно 240 мс. Чем выше это время, тем хуже доступен сервер.

Также видим, что 0% пакетов потеряно. Это говорит о том, что связь является надежной, передача сообщений происходит без потерь. В принципе, при таких условиях можно пользоваться не только протоколами ТСР, но и UDP.

У этой утилиты также есть опции, правда, список их не такой большой, как у nmap.


Утилита netstat

↑ К содержанию ↑

Если она запущена без параметров, то в консоли показывается список ВСЕХ открытых сокетов. Как PF_INET, так и PF_UNIX. Который является огромным.

Вот наиболее интересные опции:

  - показывает как слушающие, так и не слушающие сокеты. Т.е. – все.
 - показывает идентификатор и имя программы (точнее, процесса), создавшей сокет.
-n  - показывает IP-адреса в числовом виде.

Вводим
netstat -anp

Вот что выдается:

(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign Address  State  PID/Program name
tcp  0  0 127.0.1.1:53    0.0.0.0:*     LISTEN  -    
tcp  0  0 127.0.0.1:631     0.0.0.0:*     LISTEN  -    
tcp6   0  0 ::1:631     :::*      LISTEN  -    
tcp6   1  0 ::1:52687     ::1:631     CLOSE_WAIT  2744/indicator-prin
tcp6   1  0 ::1:34102     ::1:631     CLOSE_WAIT  -    
udp  0  0 127.0.1.1:53    0.0.0.0:*         -    
udp  0  0 0.0.0.0:68    0.0.0.0:*         -    
udp  0  0 0.0.0.0:68    0.0.0.0:*         -    
udp  0  0 0.0.0.0:18923     0.0.0.0:*         -    
udp  0  0 0.0.0.0:46638     0.0.0.0:*         -    
udp  0  0 0.0.0.0:631     0.0.0.0:*         -    
udp6   0  0 :::42413    :::*        -    
udp6   0  0 :::43576    :::*        -    
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags   Type   State   I-Node   PID/Program name  Path
unix  2  [ ACC ]   STREAM   LISTENING   17123  2535/gnome-session  @/tmp/.ICE-unix/2535
unix  2  [ ACC ]   STREAM   LISTENING   12296  -       /run/uuidd/request
unix  2  [ ACC ]   STREAM   LISTENING   12045  -       /var/run/acpid.socket
unix  2  [ ACC ]   STREAM   LISTENING   16786  -       /tmp/ssh-fIKSCXpZO88v/agent.2535
unix  2  [ ACC ]   STREAM   LISTENING   15254  -       @/tmp/.X11-unix/X0
unix  2  [ ACC ]   SEQPACKET  LISTENING   10286  -       /run/udev/control
unix  2  [ ACC ]   STREAM   LISTENING   114993   -       /var/run/cups/cups.sock
unix  2  [ ACC ]   STREAM   LISTENING   37477  2926/gvfsd-trash  @/dbus-vfs-daemon/socket-8ITR0Nme
unix  2  [ ACC ]   STREAM   LISTENING   37482  2926/gvfsd-trash  @/dbus-vfs-daemon/socket-fu8EIKBR
unix  2  [ ACC ]   STREAM   LISTENING   18835  2926/gvfsd-trash  @/dbus-vfs-daemon/socket-tHN7I8UR

… и т.д.

Видим, что приватного адреса вида 192.168.145.135 не показывается, вместо него – адрес 127.0.0.1. Что же касается многочисленных сокетов в домене UNIX, то это сокеты, используемые ОС без обращения к сети.


netstat -p –inet

Команда покажет активные соединения (по протоколам TCP, UDP) – только интернетные серверы, без внутренних соединений. Результат будет примерно таким:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address     Foreign Address   State   PID/Program name
tcp  0  0 ubuntu:domain     *:*       LISTEN  1449/dnsmasq  
tcp  0  0 localhost:ipp     *:*       LISTEN  3476/cupsd  
udp  0  0 ubuntu:domain     *:*         1449/dnsmasq  
udp  0  0 *:bootpc    *:*         19275/dhclient  
udp  0  0 *:bootpc    *:*         8530/dhclient  
udp  0  0 *:18923     *:*         8530/dhclient  
udp  0  0 *:46638     *:*         19275/dhclient  
udp  0  0 *:ipp       *:*         1444/cups-browsed

Утилита tcpdump

↑ К содержанию ↑

Эта утилита выдает информацию о сетевом обмене Вашего компьютера (точнее, сетевого интерфейса, функционирующего на нем) с сетью в режиме реального времени. По смыслу – она напоминает Задание 3, только, в отличие от него, имеет гораздо более широкие возможности. Эта утилита имеет множество опций. Посмотрите их, набрав
man tcpdump. Основные опции:


  • -n - Отключает преобразование IP в доменные имена. Если указано -nn, то запрещается преобразование номеров портов в название протокола.
  • -e - Включает вывод данных канального уровня (например, MAC-адреса).
  • -v (-vv или -vvv) - Вывод дополнительной или еще более дополнительной информации (TTL, опции протокола IP).
  • -w имя_файла - Задать имя файла, в который сохранять собранную информацию.
  • -r имя_файла - Чтение дампа из заданного файла.
  • -q - Переводит tcpdump в "бесшумный режим", в котором пакет анализируется на транспортном уровне (протоколы TCP, UDP, ICMP), а не на сетевом (протокол IP).
  • -t - Отключает вывод меток времени.
  • -A - дает возможность выводить в консоль не только заголовки протоколов IP, ТСР, но и данные, полученные с веб-сервера, в ASCII-виде. Это бывает очень полезно при отладке клиент-серверных приложений, когда необходимо посмотреть в консоли ответ сервера.

Кроме того, в составе ее параметров могут быть логические операторы and, or, not, т.е. можно комбинировать параметры, оформлять их в виде условий.

Запустим ее:
sudo tcpdump –v

Результат:

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:22:56.476188 IP6 (hlim 1, next-header UDP (17) payload length: 92) fe80::b96b:b3c0:2168:57f4.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=1cb96f (elapsed-time 1500) (client-ID hwaddr/time type 1 time 473390577 00093bf01a40) (IA_NA IAID:520114262 T1:0 T2:0) (Client-FQDN) (vendor-class) (option-request DNS-search-list DNS-server vendor-specific-info Client-FQDN))
14:22:57.217596 IP (tos 0x0, ttl 64, id 35850, offset 0, flags [DF], proto UDP (17), length 118)
 localhost.43108 > localhost.domain: 53116+ PTR? 2.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.f.f.ip6.arpa. (90)
14:22:57.254212 IP (tos 0x0, ttl 128, id 48342, offset 0, flags [none], proto UDP (17), length 182)
 localhost.domain > localhost.43108: 53116 NXDomain 0/1/0 (154)
14:22:57.254409 IP (tos 0x0, ttl 64, id 35851, offset 0, flags [DF], proto UDP (17), length 118)
 localhost.56391 > localhost.domain: 9796+ PTR? 4.f.7.5.8.6.1.2.0.c.3.b.b.6.9.b.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
14:22:57.299388 IP (tos 0x0, ttl 128, id 48343, offset 0, flags [none], proto UDP (17), length 170)
 localhost.domain > localhost.56391: 9796 NXDomain 0/1/0 (142)
14:22:58.301471 IP (tos 0x0, ttl 64, id 36015, offset 0, flags [DF], proto UDP (17), length 72)
 localhost.59184 > localhost.domain: 17408+ PTR? 2.145.168.192.in-addr.arpa. (44)
14:22:58.339264 IP (tos 0x0, ttl 128, id 48344, offset 0, flags [none], proto UDP (17), length 153)
 localhost.domain > localhost.59184: 17408 1/1/2 2.145.168.192.in-addr.arpa. PTR localhost. (125)
14:22:58.339682 IP (tos 0x0, ttl 64, id 36017, offset 0, flags [DF], proto UDP (17), length 74)
 localhost.38925 > localhost.domain: 23292+ PTR? 135.145.168.192.in-addr.arpa. (46)
14:22:58.372242 IP (tos 0x0, ttl 128, id 48345, offset 0, flags [none], proto UDP (17), length 155)
 localhost.domain > localhost.38925: 23292 1/1/2 135.145.168.192.in-addr.arpa. PTR localhost. (127)

Видим, что, по сути, идет сетевой обмен локального хоста с «самим собой» при помощи протокола UDP.

Расшифруем основные названия:

  • listening on eth0 - прослушиваем интерфейс под названием eth0,
  • 14:22:56.476188 - метка времени: часы, минуты, секунды, микросекунды
  • IP (tos 0x0, ttl 64, id 35850, offset 0, flags [DF], proto UDP (17), length 118) - протокол IP и параметры его заголовка: tos (type of service), это поле используется для назначения сетевой политики обслуживания пакета, т.е. задает желаемый вариант маршрутизации; ttl (time-to-live) - время жизни пакета, не указывается, если оно равно нулю; id (поле идентификации протокола IP); offset (смещение фрагмента дейтаграммы); flags (могут быть MF и DF); + присутствует, если установлен флаг MF, DF присутствует, если установлен флаг F. Если ни один из флагов не установлен, будет присутствовать . ; proto (тип протокола); length (общая длина заголовка). Далее могут идти опции протокола IP.
  • localhost.43108 - открыт порт под номером 43108 на локальном хосте

А теперь, не прерывая работы утилиты, можно попробовать открыть в браузере какую-нибудь вебстраницу (или обновить ее). Посмотрите, что получится. Рассмотрим, что будет, если в заранее открытом браузере Firefox открыть страницу 4846d.ru. Утилиту запустим со следующими параметрами:

sudo tcpdump -vnet

Так как объем информации, которой обмениваются браузер (точнее, сетевое соединение компьютера, которое использует браузер), открывающий страницу 4846d.ru, является довольно большим (почти 18 кБ), ниже рассмотрим лишь ее фрагменты, сообщаемой утилитой tcpdump, с их расшифровкой:

01:02:03:04:05:06 > 52:64:80:32:71:77, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.2 tell 10.0.2.15, length 28
52:64:80:32:71:77 > 01:02:03:04:05:06, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.0.2.2 is-at 52:64:80:32:71:77, length 46

Компьютер, имеющий МАС-адрес 01:02:03:04:05:06, имеющий IP-адрес 10.0.2.15, направляет запрос на компьютер, имеющий МАС-адрес 52:64:80:32:71:77 с помощью протокола ARP (сообщение имеет длину, равную 42 байта), используется сетевой протокол IPv4; запрос имеет следующий вид: какой МАС-адрес имеет узел с IP-адресом, равным 10.0.2.2 ?
Компьютер с МАС-адресом 52:64:80:32:71:77 отвечает источнику запроса (т.е. компьютеру с МАС-адресом 01:02:03:04:05:06) также при помощи протокола ARP, при помощи сетевого протокола IPv4, что IP-адрес, равный 10.0.2.2, имеет компьютер с МАС-адресом 52:64:80:32:71:77. Т.е. это - как раз тот самый компьютер, на который и был направлен запрос.

01:02:03:04:05:06 > 52:64:80:32:71:77, ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 34622, offset 0, flags [DF], proto UDP (17), length 54)
10.0.2.15.59127 > 10.0.0.1.53: 6707+ A? 4846d.ru. (26)

Компьютер, имеющий МАС-адрес 01:02:03:04:05:06 (с IP-адресом 10.0.2.15, порт 59127), направляет запрос на компьютер с МАС-адресом 52:64:80:32:71:77 (с IP-адресом 10.0.0.1, порт 53). Далее идет информация, касающаяся заголовков протокола IPv4, где, в частности, указано, что в качестве протокола транспортного уровня будет фигурировать UDP. А далее, после указания IP-адресов (с портами) источника и адресата указан id запроса, равный 6707; симвод + означает рекурсивный флаг. Длина запроса равна 26 байт, не включая заголовки UDP и IP протоколов. Символ А означает адресную запись. Далее указан домен, на который был направлен запрос.

01:02:03:04:05:06 > 52:64:80:32:71:77, ethertype IPv4 (0x0800), length 417: (tos 0x0, ttl 64, id 27765, offset 0, flags [DF], proto TCP (6), length 403)
10.0.2.15.46038 > 37.140.192.59.80: Flags [P.], cksum 0xf35b (incorrect -> 0xc9d2), seq 150989406:150989769, ack 22218563, win 51120, length 363: HTTP, length: 363
GET / HTTP/1.1
Host: 4846d.ru
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0

Здесь мы видим уже ТСР-запрос на IP-адрес 37.140.192.59 и на стандартный порт 80. Это - IP-адрес сервера, на котором расположена страница 4846d.ru. Отметим, что так как эта страница была открыта в браузере ранее, IP-адрес сервера был известен браузеру, поэтому трафика с использованием ARP-протокола, связанного с обращением к серверам DNS и выяснением, какому именно IP-адресу соответствует такое доменное имя, может не быть. По той же причине может отсутствовать траффик, вызванный "тройным рукопожатием" браузера и сервера.
Далее, анализируя транспортный трафик, видим, что браузер с порта 46038 передает на сервер с IP-адресом 37.140.192.59 флаг РUSH, контрольную сумму, номер последовательности 150989406, содержащей 150989769-150989406 = 363 байт данных. Это - данные, записанные в формате протокола НТТР. Ну, а дальше - сразу же идут эти данные, представляющие собой HTTP-заголовки запроса браузера, плюс байты, обозначающие пропущенную строку (что, как мы уже знаем, обозначает конец заголовков).
Обратите внимание, что длина сообщения IP-протокола составляет 417 байт, ТСР-протокола - 403 байта, а НТТР-протокола - только 363 байта. Т.е. 417 > 403 > 363. Это - следствие инкапсуляции заголовков протокола друг в друга (более высокоуровневые инкапсулируются в менее высокоуровневые). Понаблюдайте за такой последовательностью длин сообщений протоколов разных уровней во всем трафике утилиты tcpdump.

Далее сервер отправляет подтверждение принятых заголовков:

52:64:80:32:71:77 > 01:02:03:04:05:06, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 64, id 406, offset 0, flags [none], proto TCP (6), length 40)
37.140.192.59.80 > 10.0.2.15.46038: Flags [.], cksum 0x0c79 (correct), ack 363, win 65535, length 0

Затем браузер начинает поочередно делать GET-запросы для скачивания файлов CSS, JS, фавиконки.

Tcpdump и процесс "тройного рукопожатия"

Все-таки, рассмотрим процесс "тройного рукопожатия" клиента (точнее, браузера) и сервера на конкретном примере. Чтобы избежать путаницы, сделаем такие фильтры для утилиты tcpdump, которые помогут избежать вывода излишней информации:

~$ sudo tcpdump -c 9 -i enp0s3 -nS host 4846d.ru

Здесь 9 –  максимальное число захватываемых (и выводимых на экран) пакетов, после чего работа утилиты останавливается; enp0s3 – имя сетевого интерфейса (для того, чтобы его узнать, используйте другие сетевые утилиты, например, ip a. Впрочем, имя сетевого интерфейса будет показано и при запуске tcpdump, в самом начале, так что его можно подсмотреть и там.

Примечание 1. Раньше, в старых версиях Ubuntu, сетевые интерфейсы именовались примерно как eth0. Сейчас же они несколько изменены. Впрочем, имя сетевого интерфейса можно легко изменить.

Примечание 2. Число захватываемых пакетов – 9 – выбрано с запасом. В идеале, остаточно было бы трех пакетов (ибо «рукопожатие» - тройное). Но, могут наблюдаться разные нюансы, поэтому не всегда логическое соединение устанавливается в течение трех сообщений. Здесь – и качество сетевого соединения, и излишняя, иной раз, «поспешность» браузера… - см. ниже.

После чего в браузере обновим главную страницу сайта 4846d.ru. Итак, посмотрим, что получится:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enp0s3, link-type EN10MB (Ethernet), capture size 262144 bytes

  1. 00:23:53.836734 IP 10.0.2.15.46102 > 37.140.192.59.80: Flags [S], seq 2435731096, win 29200, options [mss 1460,sackOK,TS val 86332015 ecr 0,nop,wscale 7], length 0
  2. 00:23:53.876586 IP 10.0.2.15.46104 > 37.140.192.59.80: Flags [S], seq 4158226518, win 29200, options [mss 1460,sackOK,TS val 86332055 ecr 0,nop,wscale 7], length 0
  3. 00:23:53.876842 IP 10.0.2.15.46106 > 37.140.192.59.80: Flags [S], seq 3298150341, win 29200, options [mss 1460,sackOK,TS val 86332056 ecr 0,nop,wscale 7], length 0
  4. 00:23:53.898238 IP 37.140.192.59.80 > 10.0.2.15.46102: Flags [S.], seq 11328001, ack 2435731097, win 65535, options [mss 1460], length 0
  5. 00:23:53.898268 IP 10.0.2.15.46102 > 37.140.192.59.80: Flags [.], ack 11328002, win 29200, length 0
  6. 00:23:53.966816 IP 37.140.192.59.80 > 10.0.2.15.46106: Flags [S.], seq 11392001, ack 3298150342, win 65535, options [mss 1460], length 0
  7. 00:23:53.966881 IP 10.0.2.15.46106 > 37.140.192.59.80: Flags [.], ack 11392002, win 29200, length 0
  8. 00:23:53.966963 IP 37.140.192.59.80 > 10.0.2.15.46104: Flags [S.], seq 11456001, ack 4158226519, win 65535, options [mss 1460], length 0
  9. 00:23:53.966999 IP 10.0.2.15.46104 > 37.140.192.59.80: Flags [.], ack 11456002, win 29200, length 0
  10. 9 packets captured
  11. 13 packets received by filter
  12. 0 packets dropped by kernel

Рассмотрим детально информацию, выдаваемую этой утилитой. Слева видим временные метки (см. выше). Видим, что браузер послал первый запрос в момент времени 00:23:53.836734. Прождав сколько-то микросекунд, не получив ответа и, наверное, посчитав, что сервер этот запрос не получил, браузер посылает следующий запрос в момент времени 00:23:53.876586. И, вновь не дождавшись ответа, браузер посылает уже ТРЕТИЙ запрос, делая уже третью попытку соединиться с сервером. Тот, наконец-то, лишь после третьей попытки, ответил браузеру в момент времени 00:23:53.898238.

После временных меток, идут обозначения IP, т.е. работает протокол IP. В первых трех строчках направляется запрос с нашего адреса (10.0.2.15) на адрес хоста (37.140.192.59), как обычно, на открытый сервером по умолчанию порт 80. Это браузер делает запрос на сервер, пытаясь установить логическое соединение. В четвертой строчке, наоборот, сервер отвечает браузеру. И т.д.

После двоеточия в каждой строчке видим ключевое слово Flags - флаги. Сами они перечислены далее в квадратных скобках. В строчках 1…3 передается флаг SYN (обозначается как S). Затем идет номер последовательности (seq); браузер выбрал его равным 2435731096. Размер окна данных (win) установлен равным 29200 Байт.

Обратим внимание, что при очередной попытке браузера установить соединение он посылает каждый раз НОВЫЙ номер последовательности: вначале 2435731096, затем 4158226518 и, наконец, 3298150341.

В 4-й строчке мы можем наблюдать долгожданный ответ сервера только лишь на ПЕРВЫЙ(!) запрос браузера об установлении соединения. Это видно по тому, что сервер передал  acknowledgement (ack), равный 2435731097, что представляет номер последовательности 2435731096, переданный браузером в самом первом запросе, увеличенный на 1. При этом сервер, в рамках алгоритма «тройного рукопожатия», передал браузеру свой номер последовательности, равный 11328001. Сервер также посылает флаг SYN, что означает его готовность к установлению логического соединения и флаг АСК (обозначаемый точкой - .). Сообщение было отослано на порт 46102, который был открыт браузером при отсылке самого первого сообщения (см. 1-ю строчку).

Примечание: здесь имеет место омонимия названия флага АСК и номера подтверждения аск. Ибо это - разные вещи, хотя и связанные по смыслу: как флаг подтверждения ACK, так и номер подтверждения фигурируют в заголовке ТСР-протокола.

В 5-й строчке браузер передает флаг АСК (обозначаемый точкой) и номер последовательности сервера, увеличенный на 1, т.е. число 11328002. Используется также порт 46102. Итак, после получения браузером этого сообщения логическое соединение, инициированное в 1-й строчке, считается установленным.

Таким образом, каждое логическое ТСР-соединение по схеме "тройного рукопожатия" устанавливается с использованием одного и того же порта, ранее выбранного браузером.

В 6-й строчке сервер дает ответ на 3-е сообщение браузера, аналогичный данному в 4-й строчке (на 1-е сообщение): он посылает браузеру ack 3298150342.

Обратим внимание, что на 2-е сообщение браузера (2-я строчка) сервер пока не ответил…

Самое интересное, что браузер подтвердил и этот ответ сервера – в 7-й строчке, послав серверу подтвердение АСК и флаг ack 11392002 (что на 1 больше, чем принятый от сервера seq 11392001, присутствующий в 6-й строчке). Сообщение от сервера в этот раз пришло на порт 46106, а ведь именно его открыл браузер при посылке серверу сообщения в 3-й строчке.

В 8-й строчке сервер, наконец-то, отвечает на… ВТОРОЕ сообщение браузера, т.е. на 2-ю строчку. Видим, что сервер прислал ему ack 4158226519, что на 1 выше, чем 4158226518. Также сервер прислал свой номер последовательности seq 11456001 и флаги SYN, ACK.

На что браузер, в 9-й строчке, подтвердил и это логическое соединение, прислав серверу флаг АСК, подтверждение ack 11456002, большее на 1.

Таким образом, можно констатировать, что:

  • Браузер последовательно отправил три запроса об установлении соединения по номерам портов сокетов, соответственно, 46102, 46104, 46106.
  • На момент отправления браузером сообщения из 9-й строчки установлено ТРИ логических соединения между ним и сервером по открытым портам сокетов с номерами 46102, 46106, 46104 (в хронологическом порядке установления соединений). Таким образом, второе соединение, будучи инициированным ранее третьего, установилось уже после него.
  • Размер передаваемых данных равен 0, так как пока не идет речь об их передаче: происходит лишь установление трех логических соединений, передаются лишь заголовки протоколов ТСР с незаполненными полями данных.
  • После установления соединений браузер будет использовать их для выполнения, например, GET-запросов, чтобы скачать с сервера html-код, а также иные ресурсы (CSS, JS и др.). В рамках этих запросов будут передаваться совокупности байтов, синтаксически форматированных по стандарту протокола HTTP. И вот тогда-то размер передаваемых данных будет отличен от нуля.

Поле данных протокола ТСР, содержащее в себе HTTP-запрос браузера, будет содержать:

  1. Строку запроса (например, GET / HTTP/1.1),
  2. Заголовки протокола НТТР,
  3. Пустую строку (сигнализирующую сервера конец сообщения браузера).

Далее, разберем оставшиеся параметры (опции) сетевых запросов браузера и ответов сервера. В 1-й строчке мы видим:

win - количество байтов данных, ожидаемых отправителем данного, начиная с байта номер которого указан в поле подтверждения ack. Для оптимизации передачи отправитель не ждет подтверждения для каждого отправленного сегмента, а может отправить в сеть группу сегментов (но в байтах не больше размера окна). Если качество канала плохое (много запросов на повторную передачу, теряются подтверждения) окно уменьшается в размере, если хорошее — окно увеличивается.

options [mss 1460,sackOK,TS val 86332015 ecr 0,nop,wscale 7]

Опция mss (Maximum Segment Size) определяет максимальное количество байт, которое может быть получено источником сообщения в одном сегменте.

sackOK (Selective Acknowledgement) позволяет обоим участникам соединения принимать байтовые диапазоны. Обычно механизм подтверждения позволяет лишь подтвердить, что получатель имеет все данные, вплоть до специфического номера байта. В ответах сервера этот параметр отсутствует, вероятно, данный механизм не используется.

TS val / ecr используются TCP-протоколом для оценки примерного времени обработки запроса (round-trip time - RTT). TS val – это временная метка отправителя, а ecr – временная метка ответа, которая обычно представляет собой последнюю временную метку, полученную отправителем. Протокол TCP использует RTT для контроля правильности передачи.

В 1-й строчке браузер передал TS val 86332015, ecr 0. При последующих запросах браузер передавал увеличивающиеся метки времени. Вообще-то, в процессе обмена сообщениями браузера с сервером их временные метки (параметры val и ecr) должны бы меняться местами, что дополнительно будет подтверждать корректность получения сообщений. В данном случае, такой обмен почему-то не наблюдается.

Опция wscale представляет собой фактор шкалы окна. Например, если wscale = 7, win=29200 Байт, это означает, что браузер (см. 1-ю строчку) сообщает серверу, что максимальный размер его (браузера) буфера равен 7*29200 = 204400 Байт. Т.е. он может принять не более, чем 204400 Байт данных за один раз.

length – это длина сообщения (НТТР-запроса или ответа) в байтах. Включая и символы перевода строк. Сообщение в формате протокола HTTP содержится в поле данных протокола ТСР.

  1. Самостоятельное задание:
  2. Запустите утилиту, почти как было указано выше: sudo tcpdump -vne

  3. Обновите страницу сайта. После этого прервите работу утилиты (Ctrl + C) и найдите в консоли сообщения, относящиеся в первому успешному "тройному рукопожатию". Поясните, что там происходило, какие параметры использовались и почему.

Утилита arp

↑ К содержанию ↑

Утилита arp используется для преобразования IP-адресов в адреса физической сети, к которой подключен компьютер, например, Ethernet или Wifi. Суперпользователь (администратор) может добавлять и удалять аrp записи. Вот пример информации, выдаваемой этой утилитой:

arp –a
Результат:
localhost (192.168.145.254) at 00:50:56:ff:af:31 [ether] on eth0
localhost (192.168.145.2) at 00:50:56:fa:44:ec [ether] on eth0
localhost (192.168.145.1) at 00:50:56:c0:00:08 [ether] on eth0

Видим, что на данный момент в ОС имеется 3 приватных хоста на одном интерфейсе.


Заключение
↑ К содержанию ↑

Вот, пожалуй, основные утилиты по работе с сетевыми интерфейсами и сетью в Linux. В Windows есть аналогичные утилиты – многие из них даже совпадают по названию и функциональности.

На самом деле, утилит по управлению сетью и ее конфигурированию – гораздо больше. Но, мы с Вами остановимся лишь на вышеизложенных, ибо они нам пригодятся для анализа результатов работы программ, которые Вы напишете самостоятельно, в рамках Заданий 2, 3.

Итак, освоив работу с сетевыми утилитами ОС Linux, можно перейти к самостоятельной разработке программ, представляющих собой упрощенные аналоги (естественно, с весьма и весьма урезанным функционалом) этих утилит. Переходим к Заданию 2.


С уважением, Салимоненко Д.А.