TCP-порты. Список портов TCP и UDP

Порт в компьютерных сетях является конечной точкой связи в ОС. Данный термин также применяется и для аппаратных устройств, однако в программном обеспечении он обозначает логическую конструкцию, идентифицирующую конкретный вид услуг или процесс. Порт всегда связан с IP адресом хоста или типом протокола связи. Он завершает назначение адреса сеанса связи. Порт идентифицируется для каждого протокола и адреса при помощи 16-битного числа, которое также известно, как номер порта. Часто конкретные номера портов применяются для определения конкретных услуг.  Из нескольких тысяч перечисленных 1024 известных номеров защищены в соответствии со специальным соглашением. Они определяют конкретные типы услуг на хосте. Протоколы, которые в основном используют порты, применяются для управления процессами. В качестве примера можно привести протокол управления передачей TCP или User Datagram Protocol из комплекта Internet протоколов.

Значение

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

Детали

Протоколы передачи данных UDP иTCP используются для того, чтобы указать в своих заголовках сегментов номер порта назначения и источник. Номер порта – это 16-разрядное число без знака. Оно может находится в пределах от 0 до 65535. TCP порты тем не менее не могут использовать номер 0. Для UDP порт источника не обязателен. Равное нулю значение означает его отсутствие. Данный процесс связывает входные или выходные каналы посредством транспортного протокола, номера порта и адреса IP через интернет сокет. Данный процесс также известен как связывание. Он дает возможность приема и передачи информации через сеть. Сетевое ПО операционной системы используется для передачи исходящих данных всех портов приложений в сеть. Также оно осуществляет переадресацию прибывающих сетевых пакетов путем сопоставления номера и IP адреса. К определенному IP адресу и комбинации портов, используя один и тот же транспортный протокол, можно привязать только один процесс. Сбои в работе приложений, которые также называют конфликтами, возникают в тех случаях, когда сразу несколько программ пытаются связаться с одними и теми же номерами портов на том же IP адресе, используя один и тот же протокол.

Как они применяются

Приложения, которые реализуют общие службы, довольно часто используют специально зарезервированный и известный список портов UDP и TCP для приема запросов на обслуживание клиентов. Данный процесс также известен под названием прослушивание. Он включает в себя получение запроса с хорошо известного порта и установление диалога между клиентом и сервером один к другому при использовании одного и того же номера локального порта. Другие клиенты могут продолжать подключаться. Это возможно, поскольку соединение TCP идентифицируется как цепочка, которая состоит из локального и удаленного портов и адресов. Стандартные порты UDP и TCP могут быть определены по соглашению под контролем IANA или Internet Assigned Numbers Authority. Как правило, ядро сетевых сервисов, прежде всего это World Wide Web, использует небольшие номера портов, меньше 1024. Во многих ОС для приложений для привязки к ним требуются специальные привилегии. По этой причине они часто считаются критическими для работы сетей IP. Конечный клиент соединения с другой стороны, как правило, использует большее их количество, выделенных для краткосрочного использования. По этой причине и существуют так называемые эфемерные порты.

Структура

Порты TCP закодированы в заголовке пакета транспортного пакета. Они легко могут быть интерпретированы не только принимающими и передающими ПК, но и другими компонентами сетевой инфраструктуры. Межсетевые экраны в частности, как правило, настроены на различение пакетов в зависимости от номеров портов назначения и их источника. Классическим примером этому является перенаправление. Попытки подключения последовательно к диапазону портов на одном компьютере также известны как их сканирование. Подобные процедуры, как правило, связаны либо с попытками злонамеренного сбоя, либо с тем, что сетевые администраторы специально ищут возможные уязвимости для того, чтобы предотвратить подобные нападения. Действия, направленные на открытие TCP порта, регистрируются и контролируются при помощи компьютеров. Данная техника использует целый ряд запасных соединений для того, чтобы обеспечить бесперебойное взаимодействие с сервером.

Примеры использования

Основной пример, в котором активно применяются порты UDP иTCP, это почтовая система Интернет. Сервер используется для работы с электронной почтой. В целом он нуждается в двух услугах. Первый сервис применяется для транспортировки по электронной почте и с других серверов. Достигается это при помощи Simple Mail Transfer Protocol (SMTP). Приложение службы SMTP, как правило, прослушивает порт TCP номер 25 для того, чтобы обрабатывать входящие запросы. Другая услуга представляет собой POP или IMAP. Они необходимы для клиентских приложений в электронной почте на машинах пользователей для того, чтобы получать с сервера сообщения электронной почты. Прослушиваются службами POP номера с порта TCP 110. Все указанные выше службы могут запускаться на одном и том же хост-компьютере. Номер порта, когда это происходит, отличает сервис, запрашиваемый удаленным устройством. Если номер порта прослушивания сервера определен корректно, данный параметр для клиента определяется из динамического диапазона. Клиенты и сервер по отдельности в некоторых случаях используют определенные порты TCP, которые назначены в IANA. В качестве наглядного примера можно привести DHCP. Здесь клиентом в любом случае используется UDP 68, а сервером UDP 67.

Использование в URL-адресах

Иногда номера портов хорошо видны в интернете или на других унифицированных указателях информационных ресурсов, вроде URL. HTTP по умолчанию использует порт TCP 80, а HTTPS – порт 443. Также существуют и другие вариации. Так, например, адрес URL http://www.example.com:8080/pathуказывает на то, что веб-браузер вместо сервера HTTP подключается к 8080.

Список портов UDP и TCP

Как уже было отмечено ранее, IANA или InternetA ssigned Numbers Authority, несет ответственность за глобальную координацию DNS-Root, адресации IP и других ресурсов интернет протокола.  Эти процедуры включают в себя регистрацию часто используемых портов для известных интернет-сервисов. Все номера портов разделены между собой на три диапазона: хорошо известные, зарегистрированные и частные или динамические. Известными называют порты, имеющие номера от 0 до 1023. Их также называют системными. Требования, которые предъявляются к новым значения в данном диапазоне, являются более строгими, чем для других регистраций.

Примеры

К примерам портов, находящихся в списке известных, можно отнести:

• TCP 443 порт – HTTPS;
• 21 – File Transfer Protocol;
• 22- Secure Shell;
• 25 – простой протокол передачи почты STMP;
• 53 – система доменных имен DNS;
• 119 – протокол передачи сетевых новостей или NNTP;
• 80 – протокол передачи гипертекста HTTP;
• 143 – Internet Message Access Protocol;
• 123 – протокол сетевого времени NTP;
• 161- простой протокол управления сетью SNMP.

Зарегистрированные порты обязательно имеют номера от 1024 до 49151. Internet Assigned Numbers Authority поддерживает официальный перечень всех известных и зарегистрированных диапазонов. Частотные или динамические порты находятся в диапазоне от 29152 до 65535. Одним из вариантов использования данного диапазона являются временные порты.

История создания

Концепция номеров портов была разработана ранними создателями ARPANET. Она разрабатывалась в условиях неформального сотрудничества между авторами программного обеспечения и системными администраторами. В то время еще не использовался термин «номер порта». Номерной ряд удаленного хоста представлял собой 40-битное число. Первые 32 бита напоминали сегодняшний адрес IPv4. Наиболее значимыми при этом являлась первые 8 бит. Менее значимая часть числа (это биты с 33 по 40) обозначали объект под названием AEN. Он представлял собой прототип современного номера порта. Впервые создание каталога номеров сокета было предложено 26 марта 1972 года. Администраторов сети тогда призвали описать каждый постоянный номер на предмет сетевых услуг и его функций. Данный каталог впоследствии был опубликован в RFC 433 зимой 1972 года. В него вошел список хостов, их номера портов и соответствующая функция, используемая в каждом узле в сети. Впервые официальные значения номеров портов были задокументированы в мае 1972 года.  Тогда же была предложена и специальная административная функция для ведения данного реестра. В первый список портов TCP вошло 256 значений AEN.Они были разделены на следующие диапазоны:

— от 0 до 63 – стандартные функции всей сети;

— от 64 до 127 – хост-специфичные функции;

— от 128 до 239 – функции, зарезервированные для будущего использования;

— от 240 до 255 – любая экспериментальная функция.

Термином AEN в начале существования ARPANET также называли имя сокета, которое применялось с первоначальным протоколом соединения и компонентом программы для управления сетью или NCP. В данном случае NCP представлял собой предшественника современных интернет-протоколов, которые используют порты TCP/IP.

UDP — Википедия

UDP (англ. User Datagram Protocol — протокол пользовательских датаграмм) — один из ключевых элементов набора сетевых протоколов для Интернета. С UDP компьютерные приложения могут посылать сообщения (в данном случае называемые датаграммами) другим хостам по IP-сети без необходимости предварительного сообщения для установки специальных каналов передачи или путей данных. Протокол был разработан Дэвидом П. Ридом в 1980 году и официально определён в RFC 768.

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

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

UDP-приложения используют датаграммные сокеты для установки соединения между хостами. Приложение связывает сокет с его конечной точкой передачи данных, которая является комбинацией IP-адреса и порта службы. Порт — это программная структура, определяемая номером порта — 16-битным целочисленным значением (то есть от 0 до 65535). Порт 0 зарезервирован, хотя и является допустимым значением порта источника в случае, если процесс-отправитель не ожидает ответных сообщений.

IANA разбила номера портов на три группы.

• Порты с номерами от 0 до 1023 используются для обычных, хорошо известных служб. В Unix-подобных операционных системах для использования таких портов необходимо разрешение суперпользователя.
• Порты с номерами от 1024 до 49151 предназначены для зарегистрированных IANA служб.
• Порты с 49152 по 65535 могут быть использованы для любых целей, поскольку официально не разработаны для какой-то определённой службы. Они также используются как динамические (временные) порты, которые запущенное на хосте программное обеспечение может случайным образом выбрать для самоопределения. По сути, они используются как временные порты в основном клиентами при связи с серверами.

UDP — минимальный ориентированный на обработку сообщений протокол транспортного уровня, задокументированный в RFC 768.

UDP не предоставляет никаких гарантий доставки сообщения для вышестоящего протокола и не сохраняет состояния отправленных сообщений. По этой причине UDP иногда называют Unreliable Datagram Protocol (англ. — Ненадёжный протокол датаграмм).

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

Заголовок UDP состоит из четырёх полей, каждое по 2 байта (16 бит). Два из них необязательны к использованию в IPv4 (розовые ячейки в таблице), в то время как в IPv6 необязателен только порт отправителя.

Порт отправителя[править | править код]

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

Порт получателя[править | править код]

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

Длина датаграммы[править | править код]

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

На практике также следует учитывать, что если длина IPv4 пакета с UDP будет превышать MTU (для Ethernet по умолчанию 1500 байт), то отправка такого пакета может вызвать его фрагментацию, что может привести к тому, что он вообще не сможет быть доставлен, если промежуточные маршрутизаторы или конечный хост не будут поддерживать фрагментированные IP пакеты. Также в RFC 791 указывается минимальная длина IP пакета 576 байт, которую должны поддерживать все участники IPv4, и рекомендуется отправлять IP пакеты большего размера только в том случае если вы уверены, что принимающая сторона может принять пакеты такого размера. Следовательно, чтобы избежать фрагментации UDP пакетов (и возможной их потери), размер данных в UDP не должен превышать: MTU — (Max IP Header Size) — (UDP Header Size) = 1500 — 60 — 8 = 1432 байт. Для того чтобы быть уверенным, что пакет будет принят любым хостом, размер данных в UDP не должен превышать: (минимальная длина IP пакета) — (Max IP Header Size) — (UDP Header Size) = 576 — 60 — 8 = 508 байт^[2].

В Jumbogram’мах IPv6 пакеты UDP могут иметь больший размер. Максимальное значение составляет 4 294 967 295 байт (2³² — 1), из которых 8 байт соответствуют заголовку, а остальные 4 294 967 287 байт — данным.

Следует заметить, что большинство современных сетевых устройств отправляют и принимают пакеты IPv4 длиной до 10000 байт без их разделения на отдельные пакеты. Неофициально такие пакеты называют «Jumbo-пакетами», хотя понятие Jumbo официально относится к IPv6. Тем не менее, «Jumbo-пакеты» поддерживают не все устройства и перед организацией связи с помощью UDP/IP IPv4 посылок с длиной, превышающей 1500 байт, нужно проверять возможность такой связи опытным путём на конкретном оборудовании^[3].

Контрольная сумма[править | править код]

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

Метод для вычисления контрольной суммы определён в RFC 1071^[4].

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

Для расчёта контрольной суммы псевдозаголовок и UDP-сообщение разбивается на двухбайтные слова. Затем рассчитывается сумма всех слов в арифметике обратного кода (то есть кода, в котором отрицательное число получается из положительного инверсией всех разрядов числа и существует два нуля: 0х0000 (обозначается +0) и 0xffff(обозначается −0)). Результат записывается в соответствующее поле в UDP-заголовке.

Значение контрольной суммы, равное 0х0000 (+0 в обратном коде), зарезервировано и означает, что для посылки контрольная сумма не вычислялась. В случае, если контрольная сумма вычислялась и получилась равной 0х0000, то в поле контрольной суммы заносят значение 0xffff(-0 в обратном коде).

При получении сообщения получатель считает контрольную сумму заново (уже учитывая поле контрольной суммы), и, если в результате получится −0 (то есть 0xffff), то контрольная сумма считается сошедшейся. Если сумма не сходится (данные были повреждены при передаче, либо контрольная сумма неверно посчитана на передающей стороне), то решение о дальнейших действиях принимает принимающая сторона. Как правило, в большинстве современных устройств, работающих с UDP/IP-пакетами имеются настройки, позволяющие либо игнорировать такие пакеты, либо пропускать их на дальнейшую обработку, невзирая на неправильность контрольной суммы.

Пример расчёта контрольной суммы[править | править код]

Для примера рассчитаем контрольную сумму нескольких 16-битных слов: 0x398a, 0xf802, 0x14b2, 0xc281.

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

0x398a + 0xf802 = 0x1318c → 0x318d (перенос в старший разряд)
0x318d + 0x14b2 = 0x0463f → 0x463f (число положительное)
0x463f + 0xc281 = 0x108c0 → 0x08c1

В конце выполняется инверсия всех битов получившегося числа

0x08c1 = 0000 1000 1100 0001 → 1111 0111 0011 1110 = 0xf73e или, иначе — 0xffff − 0x08c1 = 0xf73e. Это и есть искомая контрольная сумма.

В документе RFC 1071^[4] приведены и другие способы расчёта контрольной суммы, в частности, с использованием 32х-разрядной арифметики.

Псевдозаголовок для IPv4[править | править код]

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

Адреса источника и получателя берутся из IPv4-заголовка. Значения поля «Протокол» для UDP равно 17 (0x11). Поле «Длина UDP» соответствует длине заголовка и данных.

Вычисление контрольной суммы для IPv4 необязательно, если она не используется, то значение равно 0.

Псевдозаголовок для IPv6[править | править код]

При работе UDP над IPv6 контрольная сумма обязательна. Метод для её вычисления был опубликован в RFC 2460:

При вычислении контрольной суммы опять используется псевдозаголовок, имитирующий реальный IPv6-заголовок:

Адрес источника такой же, как и в IPv6-заголовке. Адрес получателя — финальный получатель; если в IPv6-пакете не содержится заголовка маршрутизации (Routing), то это будет адрес получателя из IPv6-заголовка, в противном случае, на начальном узле, это будет адрес последнего элемента заголовка маршрутизации, а на узле-получателе — адрес получателя из IPv6-заголовка. Значение «Следующий заголовок» равно значению протокола — 17 для UDP. Длина UDP — длина UDP-заголовка и данных.

Надёжность и решения проблемы перегрузок[править | править код]

Из-за недостатка надёжности приложения UDP должны быть готовы к некоторым потерям, ошибкам и дублированиям. Некоторые из них (например, TFTP) могут при необходимости добавить элементарные механизмы обеспечения надёжности на прикладном уровне.

Но чаще такие механизмы не используются UDP-приложениями и даже мешают им. Потоковые медиа, многопользовательские игры в реальном времени и VoIP — примеры приложений, часто использующих протокол UDP. В этих конкретных приложениях потеря пакетов обычно не является большой проблемой. Если приложению необходим высокий уровень надёжности, то можно использовать другой протокол (TCP) или воспользоваться методами помехоустойчивого кодирования (Erasure code^ru_en).

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

Сетевые механизмы были предназначены для того, чтобы свести к минимуму возможные эффекты от перегрузок при неконтролируемых, высокоскоростных нагрузках. Такие сетевые элементы, как маршрутизаторы, использующие пакетные очереди и техники сброса, часто являются единственным доступным инструментом для замедления избыточного UDP-трафика. DCCP (англ. Datagram Congestion Control Protocol — протокол контроля за перегрузками датаграмм) разработан как частичное решение этой потенциальной проблемы с помощью добавления конечному хосту механизмов для отслеживания перегрузок для высокоскоростных UDP-потоков вроде потоковых медиа.

Многочисленные ключевые Интернет-приложения используют UDP, в их числе — DNS (где запросы должны быть быстрыми и состоять только из одного запроса, за которым следует один пакет ответа), Простой Протокол Управления Сетями (SNMP), Протокол Маршрутной Информации (RIP), Протокол Динамической Конфигурации Узла (DHCP).

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

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

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

• Упорядоченность — если два сообщения последовательно отправлены, первое сообщение достигнет приложения-получателя первым. Если участки данных прибывают в неверном порядке, TCP отправляет неупорядоченные данные в буфер до тех пор, пока все данные не могут быть упорядочены и переданы приложению.

• Тяжеловесность — TCP необходимо три пакета для установки сокет-соединения перед тем, как отправить данные. TCP следит за надёжностью и перегрузками.

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

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

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

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

• Легковесность — никакого упорядочивания сообщений, никакого отслеживания соединений и т. д. Это небольшой транспортный уровень, разработанный на IP.

• Датаграммы — пакеты посылаются по отдельности и проверяются на целостность только если они прибыли. Пакеты имеют определенные границы, которые соблюдаются после получения, то есть операция чтения на сокете-получателе выдаст сообщение таким, каким оно было изначально послано.

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

• RFC 768 — Протокол Пользовательских Датаграмм
• RFC 2460 — Интернет протокол, спецификация версии 6 (IPv6)
• RFC 2675 — IPv6 Jumbograms
• RFC 4113 — Management Information Base for the UDP
• RFC 5405 — Unicast UDP Usage Guidelines for Application Designers

• Kurose, J. F.; Ross, K. W. (2010). Computer Networking: A Top-Down Approach (5th ed.). Boston, MA: Pearson Education. ISBN 978-0-13-136548-3.
• Forouzan, B.A. (2000). TCP/IP: Protocol Suite, 1st ed. New Delhi, India: Tata McGraw-Hill Publishing Company Limited.
• [email protected]. «UDP Protocol Overview». Ipv6.com. Retrieved 17 August 2011.
• Clark, M.P. (2003). Data Networks IP and the Internet, 1st ed. West Sussex, England: John Wiley & Sons Ltd.
• RFC 2675
• Postel, J. (August 1980). RFC 768: User Datagram Protocol. Internet Engineering Task Force. Retrieved from http://tools.ietf.org/html/rfc768
• Deering S. & Hinden R. (December 1998). RFC 2460: Internet Protocol, Version 6 (IPv6) Specification. Internet Engineering Task Force. Retrieved from http://tools.ietf.org/html/rfc2460
• «The impact of UDP on Data Applications». Networkperformancedaily.com. Retrieved 17 August 2011.
• IANA Port Assignments
• Семенов Ю. А. Протокол UDP

Динамический порт — Википедия

Материал из Википедии — свободной энциклопедии

Динамический порт, или Эфемерный порт, — временный порт, открываемый соединением межсетевого протокола транспортного уровня (IP) из определённого диапазона программного стека TCP/IP.

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

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

IANA зарезервировала для использования в качестве динамических порты 49152 — 65535^[1].

Berkeley Software Distribution (BSD) использует в качестве динамических порты 1024 — 4999, хотя в большинстве случаев желательно увеличить их число.

Многие версии ядра Linux используют в качестве динамических порты 32768 — 61000 (диапазон задаётся в файле /proc/sys/net/ipv4/ip_local_port_range).

Microsoft Windows использует в качестве динамических порты 1025 — 5000^[2]. Однако начиная с версии Vista и Server 2008 использует стандартный диапазон портов IANA^[3].

FreeBSD, начиная с релиза 4.6, использует стандартный диапазон портов IANA.

В ОС Solaris версии 2.2 и выше диапазон динамических портов TCP и UDP по умолчанию начинается с 32768, однако может быть заменён администратором на стандартный.

Сканер портов — Википедия

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

Сам процесс называется скани́рованием портов или (в случае, когда осуществляется проверка многих хостов) сканированием сети́. Сканирование портов может являться первым шагом в процессе взлома или предупреждения взлома, помогая определить потенциальные цели атаки. С помощью соответствующего инструментария путём отправления пакетов данных и анализа ответов могут быть исследованы работающие на машине службы (Web-сервер, FTP-сервер, mail-сервер, и т. д.), установлены номера их версий и используемая операционная система.

Самым распространённым в Интернете стеком протоколов в настоящее время является TCP/IP. Службы, находящиеся на хостах, адресуются двумя идентификаторами: IP-адресом и номером порта. Существует 65536 возможных номеров портов. Большинство сервисов используют ограниченный набор номеров портов (номер порта закрепляется организацией IANA в случае, если сервис становится достаточно значимым^[1]).

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

Результат сканирования порта обычно подпадает под одну из трёх категорий:

• Открыт, или соединение принято (англ. open): хост послал ответ, подтверждающий, что хост «слушает» — принимает соединения на данный порт.
• Закрыт, запрещено^{[уточнить]}, не слушает (closed): хост послал ответ, показывающий, что соединения на данный порт будут отвергнуты.
• Заблокирован, отфильтрован (filtered, firewalled): от хоста не поступило ответа.

Уязвимости, связанные с открытыми портами, подразделяются на:

1. проблемы с безопасностью и стабильностью, связанные с функционированием программ, предоставляющих сервисы,
2. проблемы с безопасностью и стабильностью, связанные с операционной системой, работающей на хосте.

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

Технологии сканирования портов исходят из предположения, что хост поддерживает «Протокол управления пересылкой» (ICMP), определённый в RFC 792^[2]. Хотя это в большинстве случаев так, тем не менее, хост может посылать в ответ странные пакеты, или даже генерировать ложные положительные срабатывания, когда используемый стек TCP/IP не соответствует RFC или был подвергнут изменениям.

Проверка онлайна[править | править код]

В ряде случаев, прежде чем начать собственно сканирование, является полезной проверка наличия работающей системы на целевом IP-адресе. Эта задача может быть решена путём посылки Echo-сообщений протокола ICMP с помощью утилиты ping c последовательным перебором всех адресов сети или отправкой Echo-сообщения по широковещательному адресу.
Анализируя трафик и отслеживая Echo-сообщения, посылаемые за короткий промежуток времени всем узлам, можно выявить попытки сканирования. Вместо Echo-сообщений могут применяться TCP-сегменты с code bit RST, ответы на несуществующие DNS-запросы. Если сканер получит в ответ ICMP Destination Unreachable пакет с кодом 1 (host unreachable), то значит, тестируемый узел выключен или не подключен к сети.

Следует иметь в виду, что (на практике) неполучение ответа на запросы не гарантирует несуществование хоста, поскольку многие системные администраторы ради «безопасности» идут на нарушение сетевых стандартов.

SYN-сканирование[править | править код]

Данный тип сканирования является наиболее популярным. Вместо использования сетевых функций операционной системы, сканер портов сам генерирует IP пакеты, и отслеживает ответы на них. Эту технику часто называют сканированием с использованием полуоткрытых соединений, поскольку полное соединение TCP/IP никогда не открывается. Сканер портов генерирует пакет SYN. Если порт на целевом хосте открыт, с него придёт пакет SYN-ACK. Хост сканера отвечает пакетом RST, закрывая тем самым соединение до того, как процесс установления соединения завершился.

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

Мнения по поводу потенциального вреда, наносимого сканируемому хосту, неоднозначны. С одной стороны, SYN-сканирование имеет то преимущество, что отдельные приложения никогда не получают входящее соединение (оно обрывается на этапе установки), с другой, отправка пакета RST во время установления соединения может вызывать проблемы у некоторых сетевых устройств, особенно простых, таких как сетевые принтеры.

TCP-сканирование[править | править код]

Данный более простой метод использует сетевые функции операционной системы, и применяется, когда SYN-сканирование по тем или иным причинам неосуществимо. Операционная система, в случае, если порт открыт, завершает трёхэтапную процедуру установления соединения, и затем сразу закрывает соединение. В противном случае, возвращается код ошибки. Преимуществом данного метода является то, что он не требует от пользователя специальных прав доступа. Тем не менее, использование сетевых функций операционной системы не позволяет производить низкоуровневый контроль, поэтому данный тип используется не столь широко.

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

UDP-сканирование[править | править код]

Сканирование с помощью пакетов UDP также возможно, хотя имеет ряд особенностей. Для UDP отсутствует понятие соединения, и нет эквивалента TCP-пакету SYN. Тем не менее, если послать UDP-пакет на закрытый порт, система ответит сообщением ICMP «порт недоступен». Отсутствие такого сообщения истолковывается как сигнал того, что порт открыт. Однако, если порт блокируется брандмауэром, метод неверно покажет, что порт открыт. Если заблокированы ICMP-сообщения о недоступности порта, все порты будут казаться открытыми. Также, может быть установлено ограничение на частоту использования ICMP-пакетов, что также влияет на результаты, даваемые методом.

Альтернативным подходом является отправка UDP-пакетов, специфичных для приложения, в расчёте на получения ответа с уровня приложения. Например, отправка запроса DNS на порт 53 приведёт к ответу, если по запрашиваемому адресу имеется DNS-сервер. Проблема в данном случае состоит в наличии соответствующего «пробного» пакета для каждого из портов. В некоторых случаях, сервис может присутствовать, но быть сконфигурирован таким образом, чтобы не отвечать на известные «пробные» пакеты.

Также возможен комбинированный подход, сочетающий в себе оба вышеуказанных метода. Так, сканирование может начинаться отправкой UDP-пакета для проверки на ICMP-ответ «порт недоступен», а затем порты с неопределённым результатом «открыт или заблокирован» могут повторно проверяться на ответы, специфичные для приложения.

ACK-сканирование[править | править код]

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

FIN-сканирование[править | править код]

Некоторые серверы способны отследить попытку SYN-сканирования их портов. Например, попытка SYN-сканирования может быть распознана по поступлению «поддельных» SYN-пакетов на закрытые порты защищаемого сервера, и в случае опроса нескольких портов сервер разрывает соединение для защиты от сканирования.

Сканирование с использованием FIN-пакетов позволяет обойти подобные средства защиты. Согласно RFC 793, на прибывший FIN-пакет на закрытый порт сервер должен ответить пакетом RST. FIN-пакеты на открытые порты должны игнорироваться сервером. По этому различию становится возможным отличить закрытый порт от открытого.

Указанной рекомендации RFC 793 придерживаются не все операционные системы. Например, реакция Windows семейства 95/98/NT на приходящий FIN-пакет не различается для открытого и закрытого порта.

Другие типы сканирования[править | править код]

И ещё один способ заключается в том, чтобы отправлять сегменты с флагами FIN(no more data from sender), PSH(push function), URG(urgent pointer field significant) либо вообще с пустым полем code bit. Если порт закрыт, то в ответ придёт сегмент с флагом RST, если ответа не будет, то порт открыт (так как такой сегмент просто игнорируется).

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

Большинство брандмауэров могут защитить от сканирования портов. Брандмауэр может открыть все порты в системе, чтобы остановить показ портов тем, кто занимается сканированием. Данный метод работает в большинстве случаев, однако, не защищает от новых техник сканирования портов, в числе которых сканирование с помощью ICMP-порта и NULL-сканирование.

Некоторые провайдеры реализуют фильтры пакетов или открытые прокси-серверы, которые препятствуют исходящей активности по сканированию портов.

Моральные и юридические ограничения[править | править код]

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

Уголовным кодексом Российской Федерации предусмотрена уголовная ответственность за следующие преступления^[3]:

• Неправомерный доступ к компьютерной информации, если это повлекло уничтожение, блокирование, модификацию либо копирование информации, нарушение работы ЭВМ, системы ЭВМ или их сети;
• Создание, использование и распространение вредоносных программ для ЭВМ;
• Нарушение правил эксплуатации ЭВМ, системы ЭВМ или их сети, повлёкшее уничтожение, блокирование или модификацию информации.

• Nmap^[4] — один из самых доступных кроссплатформенных сканеров портов.
• В Mac OS X — встроенное приложение Network Utility.