Проверка открытых портов | 🔎

Почему важно знать, какие порты открыты на компьютере?

Открытый порт на вашем компьютере (если не настроен файервол для запрета входящих соединений) означает, что к вашему компьютеру можно подключиться из вне.

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

Хотя могут быть варианты, например, многие бэкдоры подключаются к компьютеру злоумышленника и ожидают команд — в этом случае правильнее говорить не об открытом порте, а об установленном соединении. Это распространённый способ поведения вредоносного ПО, поскольку в данном случае не требуется, чтобы у жертвы был белый IP (что для домашних компьютеров является редкостью).

Ещё один пример, когда нужно определить, какая именно служба прослушивает порт: вы пытаетесь установить сетевую службу (веб-сервер Apache или СУБД MySQL), а они не запускаются, так как какая-то другая служба уже заняла их порт, который они используют по умолчанию. В этом случае нужно найти эту службу и отключить её или настроить на работу с другим портом.

Но, как и во многих IT задачах (да и вообще во многих профессиональных сферах), получить данные это только самое начало. Главное — это правильно их истолковать и понять.

Поэтому в этой статье мы рассмотрим, как узнать, какие порты открыты, как проверить, какая служба прослушивает определённый порт, а также научимся правильно понимать вывод команды NETSTAT и аналогичных.

Что означает 0.0.0.0 в netstat. различные виды нотаций в netstat и ss

0.0.0.0 — это самый первый IP адрес. Но он относится к IP специального назначения (как например 127.0.0.1) и выполняет разные функции.

Обозначение 0.0.0.0 может иметь разное значение в зависимости от того, где используется. Когда говорят о прослушиваемых портах, это обозначение в Linux символизирует заполнитель, то есть означает «любой IP адрес».

Чем это отличается от * (звёздочки) или от записи :::, которые также встречаются в выводе рассматриваемых программ? В программе ss IPv6 адрес 0:0:0:0:0:0:0:0 (который является аналогом IPv4 адреса 0.0.0.0) обозначается звёздочкой (*).

В программе netstat также используется запись 0.0.0.0:* которая также обозначает «любой IPv4 адрес с любого порта».

Но в netstat для обозначения «любой IPv6 адрес с любого порта» используется :::*

Помните об этих различиях, чтобы не запутаться. А также помните о том, что если показано, что прослушивается протокол tcp6 (IPv6), то одновременно может прослушиваться порт и на tcp (IPv4) — при этом данные в выводимой информации отсутствуют!

В Windows в качестве Local Address (Локального адреса), когда прослушивается любой IP адрес на определённом порту, используется запись вида 0.0.0.0:80 (в этом примере прослушивается любой IP адрес, доступный в системе, на 80 порту). Для IPv6 адресов в этом случае используется запись вида [::]:80.

В качестве внешнего адреса, когда доступно подключения с любого IP и с любого порта, для TCP протокола пишется 0.0.0.0:0, а для UDP протокола в этих же условиях пишется *:*. Что тоже не особо логично и сбивает с толку. Точнее говоря такое различие в обозначениях вытекает из разницы протоколов TCP и UDP.

Если информация относится к IPv6, то для TCP когда имеется ввиду любой адрес на любом порту, используется запись вида [::]:0. А для UDP используются одинаковые нотации как для IP, так и для IPv6, то есть *:*

Нужно помнить, что некоторые из этих обозначений пересекаются с нотациями из Linux, где они имеют своё собственное значение.

Чтобы чуть облегчить жизнь, я составил такую табличку, которую можно использовать в качестве шпаргалки:

Ip адрес 0.0.0.0

Кстати, IP адрес 0.0.0.0 довольно интересный, так как используется в разных случаях.

Например, некоторые службы в качестве адреса привязки (bind) позволяют установить 0.0.0.0. Это означает, что служба будет прослушивать порт на всех сетевых интерфейсах данного компьютера, то есть на всех IP адресах. В некоторых службах (например, веб-сервер Apache), просто не нужно указывать никакой определённый IP адрес (в том числе 0.0.0.0) и по умолчанию они будут прослушивать входящие соединения на всех сетевых интерфейсах.

Важно понимать, что 0.0.0.0 и 127.0.0.1 это совершенно разные вещи. Хотя если в Linux пинговать 0.0.0.0, то пинги будут отправляться именно к 127.0.0.1. В Windows попытка пинга 0.0.0.0 вызовет сообщение о сбое передачи данных, то есть о недоступности адреса. Адрес 0.0.0.0 означает «любой IP данного компьютера» и включает в себя в том числе 127.0.0.1.

Адрес 0.0.0.0 обычно означает, что IP адрес ещё не настроен или не присвоен. Такой адрес указывает хост, который обращается к DHCP для получения IP адреса.

Если 0.0.0.0 указан в качестве адреса получателя, то он должен расцениваться как широковещательный адрес 255.255.255.255.

Адрес 0.0.0.0 с маской 0.0.0.0, то есть 0.0.0.0/0 используется для обозначения маршрута по умолчанию (default route).

Этот адрес не является валидным адресом для назначения сетевому интерфейсу, точно также как и вся подсеть 0.0.0.0/8 (то есть любой адрес, начинающийся с 0.).

Ip протокол

Роутер смотрит на IP адрес получателя. У роутера есть своя таблица маршрутизации, а также свой маршрут по умолчанию. Если этот TCP пакет не предназначен ни для кого в локальной сети, то роутер просто отправляет его по маршруту по умолчанию, то есть по проводу, который идёт к Интернет-провайдеру.

Мы с вами помним, что нельзя просто так отправить TCP пакет с одного устройства на другое – его нужно завернуть в конверт. В локальной сети это Ethernet кадр, но в сетях провайдера работает уже не Ethernet, а другой протокол. Не будем на этом заострять внимание, тем более что там могут быть различные варианты.

Итак, наш TCP пакет дошёл до Интернет-провайдера. Казалось бы – уже столько всего с ним приключилось, но путь TCP пакета только начался. Теперь он пропутешествует по нескольким сетям и всё-таки доберётся до веб-сервера. Каждая сеть подключена к нескольким другим сетям.

И может быть множество путей для достижения конечной точки. Например, я отправил TCP пакет из Владимирской области и пунктом его назначения является, сервер в Санкт-Петербурге. Пакет может пройти кратчайшим путём по смежным сетям, а может сначала отправится в Северную Америку, затем в Южную Америку, затем в Австралию и затем к серверу в Санкт-Петербурге.

Виды сканирований nmap

Мы рассмотрели механизм рукопожатия TCP, напомним его структуру:

• Клиент: SYN
• Сервер: SYN-ACK
• Клиент: ACK

Знаменитый сканер портов Nmap по умолчанию выполняет сканирования с использованием полуотрытых соединений, или его ещё называют SYN сканированием. На самом деле, это не что иное, как отправленный пакет с включённым флагом SYN — то есть Nmap инициирует рукопожатие TCP.

Такой метод, с одной стороны, является универсальным — любой открытый порт обязательно должен ответить пакетом с флагами SYN-ACK, поскольку это стандарт транспортного протокола TCP. Но при этом Nmap не завершает рукопожатие, то есть не создаётся полноценное соединение и приложение, которое прослушивает просканированный порт, никогда не узнает об этом неудачном TCP рукопожатии, и этот факт не отобразиться в журналах этого приложения.

Пример сканирования портов:

sudo nmap -p 70-90 185.117.153.79

На следующем скриншоте мы можем видеть отправленные и полученные пакеты:

Первая группа пакетов (выделена прямоугольником) — пинг хоста, чтобы определить, доступен ли он. Также на этапе доступности хоста делается запрос к портам 80 и 443 (хотя порт 443 не указан для сканирования), видимо, также для подтверждения того, что хост онлайн.

Если от порта получен пакет SYN-ACK (сервер готов к установке соединения), то Nmap отвечает пакетом с флагом RST для обрыва начатого рукопожатия.

Вторая группа — они отмечены серым и зелёным — это непосредственно сканирование портов — это пакеты с флагом SYN. Серым отмечены те, которые прислали ответ RST-ACK (порт закрыт), а зелёным т е, которые прислали ответ SYN-ACK (порт открыт).

Пакеты RST-ACK, а также пакеты RST (от Nmap) помечены красным.

Как можно увидеть, техника очень простая и использует самые базовые возможности трансопртного протокола TCP.

Кроме этого метода, Nmap поддерживает ещё несколько типов сканирования:

  -sS/sT/sA/sW/sM: TCP SYN/с использованием системного вызова Connect()/ACK/Window/Maimon сканирования
  -sU: UDP сканирование
  -sN/sF/sX: TCP Null, FIN и Xmas сканирования
  --scanflags <флаги>: Задать собственные TCP флаги

Заголовок tcp

• Порт источника — биты 0-15. Это порт источника пакета. Исходный порт изначально был связан напрямую с процессом в отправляющей системе. Сегодня мы используем хеш между IP-адресами и портами назначения и порта источника для достижения этой уникальности, которую мы можем привязать к одному приложению или программе.
• Порт назначения — биты 16-31. Это порт назначения пакета TCP. Как и в случае с портом-источником, он изначально был напрямую связан с процессом в принимающей системе. Сегодня вместо этого используется хеш, который позволяет нам иметь больше открытых соединений одновременно. Когда пакет получен, порты назначения и исходные порты возвращаются в ответе обратно к первоначально отправляющему хосту, так что порт назначения теперь является портом источника, а порт источника является портом назначения.

Порт источника и порт назначения не обязаны быть одинаковыми: к примеру, если делается запрос к 80-му порту сервера, то этот запрос может прийти, например, с порта 34054.

Номера портов на сервере могут использоваться как стандартные, так и произвольные.

• Порядковый номер (Sequence number) — биты 32-63. Поле порядкового номера используется для установки номера в каждом TCP-пакете, чтобы можно было правильно упорядочить поток TCP (например, пакеты приводятся к правильному порядку). Затем в поле ACK возвращается порядковый номер, чтобы подтвердить, что пакет был принят правильно.

Указывает на количество переданных байт, и каждый переданный байт полезных данных (payload) увеличивает это значение на 1.

Если установлен флаг SYN (идёт установление сессии), то поле содержит изначальный порядковый номер — ISN (Initial Sequence Number). В целях безопасности это значение генерируется случайным образом и может быть равно от 0 до 232-1 (4294967295). Первый байт полезных данных в устанавливающейся сессии будет иметь номер ISN 1.

В противном случае, если SYN не установлен, первый байт данных, передаваемый в данном пакете, имеет этот порядковый номер.

• Номер подтверждения (Acknowledgment Number (ACK SN)) — биты 64-95. Это поле используется, когда мы подтверждаем определённый пакет, полученный хостом. Например, мы получаем пакет с одним установленным порядковым номером, и если с пакетом все в порядке, мы отвечаем пакетом ACK с номером подтверждения, равным оригинальному порядковому номеру.

Если установлен флаг ACK, то это поле содержит порядковый номер октета, который отправитель данного сегмента желает получить. Это означает, что все предыдущие октеты (с номерами от ISN 1 до ACK-1 включительно) были успешно получены.

Каждая сторона подсчитывает свой Sequence number для переданных данных и отдельно Acknowledgement number для полученных данных. Соответственно Sequence number каждой из сторон соответствует Acknowledgement number другой стороны.

• Длина заголовка (смещение данных) — биты 96-99. В этом поле указывается длина заголовка TCP пакета и где начинаются фактические данные (полезная нагрузка). Поле имеет размер в 4 бита и указывает заголовок TCP в 32-битных словах. Заголовок должен всегда заканчиваться чётной 32-битной границей, даже с различными установленными опциями (опции могут отсутствовать вовсе, либо их количество может различаться). Это возможно благодаря полю Padding в самом конце заголовка TCP.

Минимальный размер заголовка составляет 5 слов, а максимальный — 15 слов, что даёт минимальный размер 20 байтов и максимум 60 байтов, что позволяет использовать до 40 байтов опций в заголовке. Это поле получило такое имя (смещение данных) из-за того, что оно также показывает расположение фактических данных от начала сегмента TCP.

Итак, длина заголовка определяет смещение полезных данных относительно начала сегмента. Например, Data offset равное 1111 говорит о том, что заголовок занимает пятнадцать 32-битных слова (15 строк*32 бита в каждой строке/8 бит = 60 байт).

Заголовок udp

Можно сказать, что заголовок UDP представляет собой очень упрощённый заголовок TCP. Он содержит порты назначения, порты источника, длину заголовка и контрольную сумму, как показано на рисунке ниже.

• Исходный порт — биты 0-15. Это порт источника пакета, описывающий, куда должен быть отправлен ответный пакет. Он может фактически быть установлено на ноль, если значение порта не применимо. Например, иногда нам не требуется ответный пакет, то тогда пакет может быть установлен на нулевой порт источника. В большинстве реализаций он установлен на некоторый номер порта.
• Порт назначения — биты 16-31. Порт назначения пакета. Это требуется для всех пакетов, в отличие от порта источника пакета.

Как и с протоколом TCP — для сервера обычно используется один из стандартных портов (например, порт 53 для DNS серверов), а порт источника выбирается произвольно для каждого соединения, обычно это номера портов с большим номером (десятки тысяч).

• Длина — биты 32-47. Поле длины указывает длину всего пакета в октетах, включая заголовок и части данных. Самый короткий возможный пакет может быть длиной 8 октетов.

Поле, задающее длину всей датаграммы (заголовка и данных) в байтах. Минимальная длина равна длине заголовка — 8 байт. Теоретически, максимальный размер поля — 65535 байт для UDP-датаграммы (8 байт на заголовок и 65527 на данные). Фактический предел для длины данных при использовании IPv4 — 65507 (помимо 8 байт на UDP-заголовок требуется ещё 20 на IP-заголовок).

• Контрольная сумма — биты 48-63. Контрольная сумма — это та же контрольная сумма, что и в заголовке TCP, за исключением того, что она содержит другой набор данных. Другими словами, это дополнение к сумме дополнительных частей заголовка IP, всего заголовка UDP, данных UDP и дополнения нулями в конце, когда это необходимо.

Поле контрольной суммы используется для проверки заголовка и данных на ошибки. Если сумма не сгенерирована передатчиком, то поле заполняется нулями. Поле не является обязательным для IPv4.

Как в windows узнать, какая программа прослушивает порт (с помощью powershell)

В этом примере будет получено имя процесса, связанного с каждым открытым портом:

Get-NetTcpConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess,@{Name="Process";Expression={(Get-Process -Id $_.OwningProcess).ProcessName}} | Sort-Object -Property LocalPort | Format-Table

Эта команда покажет все процессы связанные с любой сетевой активностью (открытые порты, а также установленные соединения и другие статусы):

Get-NetTcpConnection | Select-Object LocalAddress,LocalPort,OwningProcess,@{Name="Process";Expression={(Get-Process -Id $_.OwningProcess).ProcessName}} | Sort-Object -Property LocalPort | Format-Table

Чтобы узнать, какая именно программа прослушивает определённый порт, используйте следующий набор команд:

$port='80';
Get-NetTcpConnection -State Listen | Where-Object {$_.LocalPort -eq "$port"} | Select-Object LocalAddress,LocalPort,OwningProcess,@{Name="Process";Expression={(Get-Process -Id $_.OwningProcess).ProcessName}} | Sort-Object -Property LocalPort | Format-Table

Замените «80» в первой строке на порт, который вас интересует.

Чтобы просмотреть идентификатор процесса-владельца используемого порта UDP, запустите команду:

Get-NetUDPEndpoint | Select-Object LocalAddress,LocalPort,OwningProcess | Sort-Object -Property LocalPort | Format-Table

Используйте следующую команду, чтобы отобразить имя процесса, открывшего UDP порт:

Get-NetUDPEndpoint | Select-Object LocalAddress,LocalPort,OwningProcess,@{Name="Process";Expression={(Get-Process -Id $_.OwningProcess).ProcessName}} | Sort-Object -Property LocalPort | Format-Table

Как заблокировать доступ к портам на компьютере?

Для настройки доступа к портам используйте файервол (в Windows называется Брандмауэр).

Многие антивирусы сейчас имеют файерволы. Настройки для входящих подключений регулируют, к каким службам, прослушивающим порт, разрешено подключаться. Эти правила не подействуют, если какая-либо служба сама инициирует соединение — для таких случаев настраиваются правила для исходящих подключений.

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

Чтобы открыть «Брандмауэр Защитника Windows» выполните в командной строке:

Firewall.cpl

Чтобы открыть «Монитор брандмауэра Защитника Windows в режиме повышенной безопасности» (правильнее было бы всё-таки сказать «продвинутой безопасности», а не «повышенной»), в командной строке выполните:

WF.msc

Чтобы открыть «Разрешение обмена данных с приложениями в брандмауэре Защитника Windows» выполните:

explorer 'shell:::{4026492F-2F69-46B8-B9BF-5654FC07E423} -Microsoft.WindowsFirewallpageConfigureApps'

Канальный уровень (data link) – передача данных с устройства на устройство

Операционная система не имеет ничего против. Но есть одна загвоздка: TCP пакеты нельзя просто передать по сети. Как если бы вы своё письмо маме написали на бумаге и пришли на почту отправлять – первое, что вас попросят, это запечатать ваше письмо в конверт.

Но тут же мы сталкиваемся со следующей загвоздкой: Ethernet кадры в качестве адреса получателя и отправителя используют MAC-адреса. Имя сайта мы знаем, IP адрес знаем, даже знаем страницу, которую запросил пользователь, а вот MAC-адреса у нас нет…

И дело здесь не в какой-то прихоти. Мы подходим к моменту, когда данные будут переданы с устройства на другое устройство. Чтобы это сделать, нужно знать физический адрес этого другого устройства – тот самый MAC-адрес.

Допустим, нужно отправить TCP пакеты на IP адрес 192.168.0.175. Операционная система начинает с того, что определяет, принадлежит ли запрашиваемый IP к локальной сети или нет. Если принадлежит к локальной сети, то она смотрит в ARP таблицу, есть ли там информация об 192.168.0.175:

Если есть, то она смотрит MAC адрес устройства, у которого IP 192.168.0.175. Пакет TCP заворачивается в Ethernet кадр, в этом кадре есть область с теми самыми данными, которые нужно передать, а также есть заголовок, в этом заголовке сказано для какого MAC-адреса предназначается пакет и какой MAC-адрес у отправителя. Ethernet кадр отправляется на сетевой интерфейс. Пока не будем следовать за ним, а рассмотрим другие варианты.

Если нужный IP не найден в ARP таблице, то по локальной сети делается широковещательный запрос «у кого IP 192.168.0.175?». В ответ устройство с IP 192.168.0.175 присылает свой MAC-адрес. Когда приходит ответ, полученный MAC добавляется в ARP таблицу (а вдруг ещё пригодится) и делается уже знакомый нам Ethernet кадр, который отправляется на сетевой интерфейс.

Если же IP, куда нужно отправить TCP пакет, не в локальной сети, то операционная система смотрит адрес шлюза по умолчанию. На этот шлюз отправляются все пакеты, которые не принадлежат к локальной сети и для которых не прописаны специальные маршруты. Так вот, операционная система смотрит IP шлюза по умолчанию, затем ищет этот IP в ARP таблице – получает MAC-адрес шлюза по умолчанию. После этого TCP пакет заворачивается в Ethernet кадр.

Напомню, мы ещё только пытаемся отправить первый TCP пакет нашего запроса к веб-серверу…

Итак, наконец-то Ethernet кадр попал в локальную сеть. Если его встречает свитч (устройство, которое вообще не понимает IP адреса, да и которому это не нужно) – оно смотрит на MAC-получателя и перенаправляет Ethernet кадр в сторону получателя. Допустим, что веб-сервер не в нашей локальной сети, тогда наш путешественник Ethernet кадр в конечном счёте попадает на роутер. Первое, что делает роутер, это разворачивает Ethernet кадр, то есть достаёт из него TCP пакет.

На какие открытые порты нужно обращать внимание

Я упоминал, что если на компьютер попала вредоносная программа, которая открыла соединение для связи со злоумышленником, то она будет прослушивать один из портов. В этом случае для TCP состояние подключения будет LISTENING или ESTABLISHED. Протокол UDP является «безстатусным», поэтому для него ничего не пишется, но нужно знать, что через UDP точно также может происходить обмен информацией.

Нужно помнить, что легитимные службы, которые открыты для доступа из вне, могут быть подвергнуты атакам, например, брут-форс пароля или эксплуатация уязвимостей. Что касается вредоносных программ, то они могут использовать любые порты. Поэтому нет готового списка портов, на которые нужно обращать внимание. Любой порт может быть признаком проблемы с безопасностью компьютера.

Трояны и бэкдоры могут действовать двумя методами:

• открывать порт и ждать подключения злоумышленника;
• самостоятельно подключаться к удалённой системе злоумышленника.

При втором варианте состояние подключения НЕ будет LISTENING — вредоносную программу можно найти только путём полного анализа всех соединений.

Как правило, службы, которые прослушивают только IP адрес 127.0.0.1, то есть слушающие на петлевых интерфейсах, предназначены для обслуживания каких-либо легитимных программ, запущенных на вашей системе.

Применение онлайн-ресурсов

Очень часто вопрос о том, как узнать, открыт ли порт, применяемый какой-либо программкой или онлайн-игрой (особенно если нужно, чтобы он был доступным из Интернета), без помощи определенных ресурсов не решить. Связано это именно с тем, что доступность какого-либо порта должна быть проверена извне — при попытке доступа к личной машине, не иначе.

Для этих целей можно применять много сайтов, которые могут проверить подключение и статус определенного открытого порта. К примеру, в виде средства ускоренной проверки можно задействовать раздел Port-scanner, который находится на ресурсе WhatsMyIP.org.

Причины недоступности

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

• Иногда нужно проверять настройки TCP/IP и делать проверку открытого порта. В редких случаях необходимо удостовериться в корректности настроек маршрутизатора, особенно в варианте пробросов порта на модеме. Также стоит взглянуть на настройки брандмауэра — возможно, именно он начинает блокировать порты. Наконец, не забывайте и вариант того, что сейчас порт может быть открытым, а временный промежуток его пинга (отклика) завершился.
• Что же насчет проверки самих портов, можно понять из всего выше сказанного, выполняется она очень просто. Поэтому если, допустим, у простого пользователя возникает такая неисправность, паниковать точно не нужно. Любое из изложенных решений помогает произвести эти операции за считаные секунды.
• Понятно, что при проверке, например, в реальном времени, человек должен точно знать, какой конкретно порт ему необходим. Но иногда неисправность может быть из-за того, что этот порт закрыт провайдером.

Протокол tcp

Transmission Control Protocol (TCP, протокол управления передачей) — один из основных протоколов передачи данных интернета, предназначен для управления передачей данных.

Из-за перегрузки сети, балансировки нагрузки трафика или непредсказуемого поведения сети, IP-пакеты могут быть потеряны, дублированы или доставлены не в неправильном порядке. TCP обнаруживает эти проблемы, запрашивает повторную передачу потерянных данных, переупорядочивает неупорядоченные данные и даже помогает минимизировать перегрузку сети, чтобы уменьшить возникновение других проблем.

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

TCP широко используется во многих интернет-приложениях, включая World Wide Web (WWW), электронную почту, протокол передачи файлов, Secure Shell, одноранговый обмен файлами и потоковое мультимедиа.

Протокол TCP оптимизирован для точной доставки, а не для своевременной доставки, и может вызывать относительно длительные задержки (порядка секунд) при ожидании сообщений, вышедших из строя или повторных передач потерянных сообщений. Поэтому он не особенно подходит для приложений реального времени, таких как передача голоса по IP.

Итак, механизм TCP предоставляет поток данных с предварительной установкой соединения, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета, гарантируя тем самым, в отличие от UDP, целостность передаваемых данных и уведомление отправителя о результатах передачи.

Алгоритм работы TCP следующий:

1. Устанавливается трёхэтапное рукопожатие между двумя узлами. На этом этапе узлы согласуют два числа — начальные номера первого пакета для каждого из узлов.
2. При отправке пакетов узлы последовательно номеруют их, то есть каждому сетевому пакету присвоен один из последовательных номеров.
3. В дополнении к номеру, для каждого пакета рассчитывается контрольная сумма. Получив пакет, вновь рассчитывается контрольная сумма для полученных данных — если она не совпадает, значит пакет был повреждён при передаче.
4. Итак, поскольку все пакеты имеют последовательные номера, то становится видно если какие-то из них отсутствуют. В этом случае отправляется запрос на повторную отправку пакета.
5. Если для какого-то пакета не совпала контрольная сумма, то отправляется запрос на повторную отправку пакета.

В общем, используя два простых механизма — контрольную сумму и последовательную нумерацию каждого пакета — удаётся достичь надёжности передачи данных и возможности организовать их в правильную последовательность независимо от того, в каком порядке они доставлены.

Всё это возможно с помощью заголовков TCP пакета.

Протокол udp

Если вы смогли разобраться с TCP и его заголовками, то с UDP вам будет совсем просто.

Протокол пользовательских дейтаграмм (UDP) — это очень простой протокол. Он был разработан для обеспечения очень простой передачи данных без какого-либо обнаружения ошибок. Это так называемый stateless (то есть «без состояния») протокол, это отличает его от протокола TCP, в котором есть понятие соединения (stateful), включающее в себя создания подключения (трёхэтапное рукопожатие) и в котором передача данных выполняется только в рамках данного подключения. Соответственно, для протокола UDP не предусмотрены различные состояния клиента и сервера.

Однако он очень хорошо подходит для приложений типа запрос/ответ, таких как, например, DNS и т. д., поскольку мы знаем, что если мы не получим ответ от DNS-сервера, запрос где-то был потерян. Иногда также стоить использовать протокол UDP вместо TCP, например, когда мы хотим только обнаружение ошибок/потерь, но не заботимся о последовательности пакетов. Это устраняет некоторые издержки, связанные с протоколом TCP.

Природа UDP как протокола без сохранения состояния также полезна для серверов, отвечающих на небольшие запросы от огромного числа клиентов, например DNS и потоковые мультимедийные приложения вроде IPTV, Voice over IP, протоколы туннелирования IP и многие онлайн-игры.

Сессия tcp

Рукопожатие TCP (установление подключения TCP)

Для установления соединения TCP использует трёхэтапное рукопожатие.

Подключение можно выполнить только если вторая сторона прослушивает порт, к которому будет выполняться подключение: к примеру, веб-сервер прослушивает порты 80 и 443. То есть это не охватывается рукопожатием, но прежде чем клиент попытается соединиться с сервером, сервер должен сначала подключиться к порту и начать прослушивать его, чтобы открыть его для соединений: это называется пассивным открытием.

Первый этап, отправка пакета с включённым флагом SYN: активное открытие выполняется клиентом, отправляющим SYN на сервер. Клиент устанавливает порядковый номер сегмента на случайное значение A.

Обратите внимание, что по умолчанию Wireshark показывает относительное значение порядкового номера (Sequence number), чуть ниже вы также можете видеть реальное значение (показано как raw).

Второй этап, отправка пакета с включённым флагом SYN-ACK: В ответ сервер отвечает SYN-ACK. Номер подтверждения установлен на единицу больше принятого Порядкового номера (Sequence number), то есть A 1. Поскольку сервер также будет отправлять данные, то для себя он тоже выбирает Порядковый номер (Sequence number) первого пакета с данными, который будет другим случайным числом B.

Третий этап, отправка пакета с включённым флагом ACK: наконец, клиент отправляет ACK обратно на сервер. Порядковый номер устанавливается равным полученному значению подтверждения, то есть A 1, а номер подтверждения устанавливается на единицу больше, чем принятый порядковый номер, то есть B 1.

На этом этапе и клиент, и сервер получили подтверждение соединения. Шаги 1, 2 устанавливают параметр соединения (порядковый номер) для одного направления, и оно подтверждается. Шаги 2, 3 устанавливают параметр соединения (порядковый номер) для другого направления, и он подтверждается. Таким образом устанавливается полнодуплексная (двухсторонняя) связь.

Передача данных в TCP

Службы *.socket

В Linux вместо запуска службы на определённом порту можно настроить сокет для прослушивания порта. Схема работы следующая: сетевая служба (например, это можно настроить для SSH) по умолчанию не запущена и, следовательно, не потребляет системные ресурсы.

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

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

Например, для SSH netstat будет показывать примерно следующие данные (1/init вместо sshd):

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp6       0      0 :::22                   :::*                    LISTEN      1/init 

А ss будет показывать примерно так:

Состояния клиента и сервера

Способ 5: служба telnet

В системах, начиная с Windows 7 и далее, данная служба по умолчанию отключена, поэтому сперва необходимо ее активировать. Если вы уже делали это в своей системе, сразу переходите к шагу 5.

1. Запустите «Панель управления», введя ее название в поисковую строку меню «Пуск» или нажав по иконке правой кнопкой мыши и выбрав соответствующий пункт.



2. В Панели найдите пункт «Программы и компоненты».



3. В появившемся окне найдите строку «Включение или отключение компонентов Windows» (слева сверху).



4. Теперь отыщите в появившемся списке пункт «Клиент Telnet» и активируйте его, установив галочку.



5. Запустите командную строку любым из описанных ранее способов, введите в нее команду telnet и нажмите «Enter».



6. Произойдет запуск Microsoft Telnet. Теперь просто введите IP адрес или домен, который необходимо проверить (можно свой) и интересующий порт. Если соединение будет успешно установлено (и порт открыт), появится либо полностью пустое окно, либо приветствие сервера. Отображение ошибки будет означать, что порт недоступен (закрыт).

Рассмотренные выше способы позволяют с легкостью проверить на открытость любой порт, TCP или UDP, а также произвести полное сканирование портов указанного адреса.

Сравнение udp и tcp

TCP — ориентированный на соединение протокол, что означает необходимость «рукопожатия» для установки соединения между двумя хостами. Как только соединение установлено, пользователи могут отправлять данные в обоих направлениях.

• Надёжность — TCP управляет подтверждением, повторной передачей и тайм-аутом сообщений. Производятся многочисленные попытки доставить сообщение. Если оно потеряется на пути, сервер вновь запросит потерянную часть. В TCP нет ни пропавших данных, ни (в случае многочисленных тайм-аутов) разорванных соединений.
• Упорядоченность — если два сообщения последовательно отправлены, первое сообщение достигнет приложения-получателя первым. Если участки данных прибывают в неверном порядке, TCP отправляет неупорядоченные данные в буфер до тех пор, пока все данные не могут быть упорядочены и переданы приложению.
• Тяжеловесность — TCP необходимо три пакета для установки сокет-соединения перед тем, как отправить данные. TCP следит за надёжностью и перегрузками.
• Потоковость — данные читаются как поток байтов, не передается никаких особых обозначений для границ сообщения или сегментов.

UDP — более простой, основанный на сообщениях протокол без установления соединения. Протоколы такого типа не устанавливают выделенного соединения между двумя хостами. Связь достигается путём передачи информации в одном направлении от источника к получателю без проверки готовности или состояния получателя.

В приложениях для голосовой связи через интернет-протокол (Voice over IP, TCP/IP) UDP имеет преимущество над TCP, в котором любое «рукопожатие» помешало бы хорошей голосовой связи. В VoIP считается, что конечные пользователи в реальном времени предоставят любое необходимое подтверждение о получении сообщения.

• Ненадёжный — когда сообщение посылается, неизвестно, достигнет ли оно своего назначения — оно может потеряться по пути. Нет таких понятий, как подтверждение, повторная передача, тайм-аут.
• Неупорядоченность — если два сообщения отправлены одному получателю, то порядок их достижения цели не может быть предугадан.
• Легковесность — никакого упорядочивания сообщений, никакого отслеживания соединений и т. д. Это небольшой транспортный уровень, разработанный на IP.
• Датаграммы — пакеты посылаются по отдельности и проверяются на целостность только если они прибыли. Пакеты имеют определенные границы, которые соблюдаются после получения, то есть операция чтения на сокете-получателе выдаст сообщение таким, каким оно было изначально послано.
• Нет контроля перегрузок — UDP сам по себе не избегает перегрузок. Для приложений с большой пропускной способностью возможно вызвать коллапс перегрузок, если только они не реализуют меры контроля на прикладном уровне.
• Широковещательные рассылки (Broadcasts) — при отсутствии соединения, UDP может делать широковещательные рассылки — отправленные пакеты могут быть адресованы для приёма всеми устройствами в подсети.
• Многоадресная рассылка (Multicast) — поддерживается многоадресный режим работы, при котором один пакет дейтаграмм может быть автоматически направлен без дублирования группе подписчиков.

Сходства и различия tcp и udp

В первой части «Как работают компьютерные сети» мы узнали, что для передачи информации используются транспортные протоколы TCP и UDP. В физическом смысле эти протоколы представляют собой сетевые пакеты. Каждый сетевой пакет передаёт небольшой фрагмент информации, поэтому данные разбиваются на много пакетов.

Каждый сетевой пакет обоих протоколов TCP и UDP состоит из двух частей:

• заголовок
• непосредственно данные

В заголовке содержится «служебная информация» (можно сказать, что это метаданные) — порты пункта назначения и исходного узла, номер пакета в потоке, тип пакета и так далее.

Различие между протоколами TCP и UDP в том, что протокол TCP имеет механизм контроля полноты переданных данных — если какой-либо пакет был потерян или повреждён, то предусмотрен механизм для проверки этого факта и повторной отправки пакета. В протоколе UDP такого механизма нет — то есть если потерян пакет протокола UDP, то узел, который его отправил, никогда об этом не узнает, а принимающая сторона никогда не узнает, что ей был отправлен потерянный пакет UDP.

Может возникнуть вопрос, зачем вообще нужен такой ненадёжный протокол UDP, если есть надёжный протокол TCP? Платой за надёжность протокола TCP является то, что в бухгалтерии называется «накладные расходы» (overheads) — суть в том, что для обеспечения механизма контроля доставки пакетов в протоколе TCP отправляется много данных, которые не содержат полезной информации, а служат только для установки и контроля соединения.

К примеру, чтобы отправить хотя бы одни пакет с полезными данными в TCP нужно завершить трёхступенчатое рукопожатие, которое заключается в отправке 1 особого пакета от источника к пункту назначения, получения 1 пакета о возможности установить соединения и отправки ещё 1 специального пакета от источника с подтверждением, что всё готово к отправке — за это время с помощью протокола UDP можно было бы отправить уже несколько пакетов с полезными данными.

Фильтры wireshark для tcp

Чтобы увидеть только трафик TCP:

tcp

Показать трафик, источником или портом назначения которого является определённый порт, например 8080:

tcp.port==8080

Показать трафик, источником которого является порт 80:

tcp.srcport == 80

Показать трафик, который отправляется службе, прослушивающей порт 80:

tcp.dstport == 80

Показать TCP пакеты с включённым флагом SYN:

tcp.flags.syn==1

Показать TCP пакеты с включённым флагом SYN и отключённым флагом ACK:

tcp.flags.syn==1 && tcp.flags.ack==0

Аналогично и для других флагов:

tcp.flags.syn==1

tcp.flags.ack==1

tcp.flags.reset==1

tcp.flags.fin==1

tcp.flags.cwr==1

tcp.flags.ecn==1

tcp.flags.urg==1

tcp.flags.push==1

tcp.flags.ns==1

Также можно использовать синтаксис вида tcp.flags == 0x0XX, например:

• FIN это tcp.flags == 0x001
• SYN это tcp.flags == 0x002
• RST это tcp.flags == 0x004
• ACK это tcp.flags == 0x010
• Установленные одновременно ACK и FIN это tcp.flags == 0x011
• Установленные одновременно ACK и SYN это tcp.flags == 0x012
• Установленные одновременно ACK и RST это tcp.flags == 0x014

Длина заголовка (смещение данных):

tcp.hdr_len == 32
tcp.hdr_len == 52
tcp.hdr_len > 32

Пакеты с установленными зарезервированными битами:

tcp.flags.res == 1

Размер окна:

tcp.window_size_value == 11
tcp.window_size_value == 4468
tcp.window_size_value > 65000
tcp.window_size_value < 100

Вычесленный размер окна:

tcp.window_size == 45056
tcp.window_size == 11

Фактор масштабирования размера окна:

tcp.window_size_scalefactor == 4096

tcp.window_size_value — это необработанное значение размера окна, считываемое непосредственно из заголовка TCP, тогда как tcp.window_size — это вычисленный размер окна, который основан на том, применимо ли масштабирование окна или нет.

Если масштабирование окна не используется или коэффициент масштабирования равен 1 или неизвестно, применимо ли масштабирование окна или нет, потому что трёхэтапное рукопожатие TCP не было захвачено, тогда эти два значения будут одинаковыми.

С помощью tcp.window_size_scalefactor вы можете определить, какое из этих условий применимо — если его значение равно -1, то оно неизвестно, если его значение равно -2, тогда масштабирование окна не используется, а все остальные значения представляют фактический размер фактора масштабирования окна.

Чтобы показать пакеты, содержащие какую либо строку, например, строку hackware:

tcp contains hackware

Следовать потоку TCP с номером X:

tcp.stream eq X

Фильтровать по номеру потока:

tcp.seq == x

Показать повторные отправки пакетов. Помогает прослеживать замедление производительности приложений и потери пакетов:

tcp.analysis.retransmission

Этот фильтр выведен проблемные пакеты (потерянные сегменты, повторную отправку и другие. Этот фильтр проходят пакеты TCP Keep-Alive, но они не являются показателем проблем.

tcp.analysis.flags

Фильтры для оценки качества сетевого подключения.

Следующие характеристики относятся к TCP фреймам. Причём они не основываются на заголовках фрейма — рассматриваемые характеристики (пропуск данных, дубли) присвоены программой Wireshark исходя из анализа.

Фильтр выводит информацию о фреймах с флагом ACK, которые являются дублями. Большое количество таких фреймов может говорить о проблемах связи:

tcp.analysis.duplicate_ack_num == 1

Фильтр показа фреймов для которых не захвачен предыдущий сегмент:

tcp.analysis.ack_lost_segment

Это нормально в начале захвата данных — поскольку информация перехватывается не с самого начала сессии.

Для показа фреймов, которые являются ретрансмиссией (отправляются повторно):

tcp.analysis.retransmission

Вывод фреймов, которые получены не в правильном порядке:

tcp.analysis.out_of_order