В 1995 году Тату Илонен написал письмо длиной с пост на Хабре и бесплатно получил номер ssh -p 22 user@host, который теперь знает каждый сисадмин. Но до этого порты были однонаправленными, чётные номера считались ненужными, а половина слотов вообще пустовала. О том, как порты стали «дверями» в сервер и что останется от них через десять лет, рассказал в статье. 

Когда порты умели только слушать 

В начале 1970-х ARPANET был в зачатках, TCP ещё не существовал, а единственным протоколом передачи данных был однонаправленный Network Control Protocol (NCP). Но для полноценного обмена данными нужно было два соединения — одно туда, другое обратно, поэтому инженеры разделили номера на нечётные для исходящего трафика и чётные для входящего. 

В итоге Telnet получил 1, FTP — 3, Echo — 7, а Discard — 9. Все ключевые сервисы были на нечётных числах, потому что чётные стали зеркальными половинками для обратного канала. Гомосокетальность в прямом смысле была запрещена на уровне протокола. 

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

Кстати, порт 0 технически существует, но в заголовке TCP он означает динамическое назначение, а в сокетах Беркли sin_port = 0 при bind() говорит ядру выбрать самому. 

Джон Постел и книга всех номеров

В мае 1972 года аспирант UCLA по имени Джон Постел написал RFC 349 — документ, который по последствиям сопоставим с изобретением колеса. Он предложил назначить «царя», который будет выдавать официальные сокетные номера и вести список, и мягко намекнул, что этим «царём» мог бы быть он. К слову, «царь» — это не моё художество, так серьёзно было написано в документе (он ниже). 

Так Постел стал «царём интернета». Он редактировал RFC 791, 792, 793 (IP, ICMP и TCP), а также вёл Assigned Numbers — периодически обновляемый документ, который для сетевых инженеров того времени был важнее телефонной книги.  

Когда Тим Бернерс-Ли в январе 1992 года написал, что хочет HTTP на порту 80, Постел одобрил ему эту просьбу в тот же день. В исходниках первого в мире веб-браузера до сих пор стоит комментарий, что порт выделен Джоном Постелем 24 января 1992 года.

Постел работал по принципу, который позже назовут Robustness Principle — «Будь консервативен в том, что отправляешь, и либерален в том, что принимаешь». Это, по его мнению, касалось и протоколов, и людей. Он выдавал порты быстро, без бюрократии, почти по одному email, потому что понимал, что интернет растёт, и тормозить его рост нельзя. 

Билл Джой и сокеты Беркли

Примерно в это же время в Беркли (нежелательная организация в РФ) американский программист Билл Джой работал над версией 4.2 операционки BSD. Для того чтобы ускорить разработку, DARPA, финансирующая разработку, поручила написание стека TCP/IP компании BBN. Однако их код еле-еле тянул 50 кбит/с, поэтому Джой переделал всё сам. 

Когда BBN прислала новую официальную версию, Джой отказался её принимать, ведь у Беркли уже был стек, который летал на 3 Мбит/с. Позже на совещании он сказал, что всё очень просто — читаешь протокол и пишешь код.

В 4.2 BSD, выпущенной уже в августе 1983 года, появился Berkeley sockets API (сокеты Беркли): socket(), bind(), listen() и accept(). Джой интегрировал сокеты с файловыми дескрипторами Unix, и сокет стал файлом, порт — его адресом, а системный вызов — рукояткой той самой «двери» порта. 

Время шло, и 1 января 1983 года ARPANET отключил NCP и перешёл на TCP/IP. Новый протокол был двухсторонним, поэтому чётные порты практически мгновенно потеряли смысл. 2, 4, 6, 8, 10, 12 и дальше по списку остались зарезервированными, но никогда не использованными слотами. 

Теперь уже «бесконечными» стали шестнадцать бит адресного пространства, то есть 65536 портов. Однако сегодня и этот диапазон периодически заканчивается даже на вполне обычных серверах.

Как получить порт за один день

Даже после перехода на TCP/IP Telnet передавал пароли открытым текстом, rlogin доверял практически всем IP-адресам, а FTP требовал отдельного канала, который файрволы с радостью дропали. Нужен был новый протокол… И вот весной 1995 года финский исследователь Тату Илонен закончил свою программу для безопасного удалённого доступа — Secure Shell, в простонародье SSH. Для этого протокола нужен был порт. 

10 июля 1995 года, в 11:45 по хельсинкскому времени, Илонен отправил письмо в IANA. В нём он написал, что разработал программу для безопасного удалённого входа через недоверенные сети. Илонен отметил, что планирует распространять SSH бесплатно и просит выделить ему зарегистрированный привилегированный порт, желательно в диапазоне 1–255, чтобы сервис можно было корректно указывать в WKS-записях DNS. 

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

В тот же день, в 15:35 по тихоокеанскому времени, ему пришёл ответ от Джойс К. Рейнольдс из IANA:  

Небольшое письмо Илонена помогло официально закрепить 22 порт за SSH. 

Как порты стали маской

IPv4-адреса заканчивались быстрее, чем предполагали инженеры, нужно было новое решение. Оно нашлось в 1994 году, когда рабочая группа IETF выпустила RFC 1631, описав NAT — механизм в сетях TCP/IP, позволяющий преобразовывать IP-адреса транзитных пакетов. С этого времени порт перестал быть просто адресом сервиса внутри машины, он стал ещё и идентификатором конкретного клиента за роутером. 

Два года спустя, в 1996 году, появилась технология PAT. Роутер начал переписывать source port у исходящих соединений, и сотни устройств в офисе могли работать через один внешний адрес одновременно. 

Это работало настолько хорошо, что интернет по сути забросил end-to-end принцип, ведь узел за NAT стал недостижим извне без заранее созданного правила проброса. 

Контейнеры добавили ещё один слой. Например, хостовый 8080 проксируется во внутренний 80 контейнера, но в ядре находятся всё те же хеш-таблицы, всё тот же tcp_v4_rcv() и всё те же 16 бит. Именно поэтому порты до сих пор остаются «дверями».

Когда у «дверей» проверяют «замки»

Если порт — это «дверь», то рано или поздно кто-то начнёт стучать во все подряд. Так, в сентябре 1996 года провайдер PANIX из Нью-Йорка обнаружил, что его почтовые серверы перестали отвечать из-за того, что кто-то слал поток SYN-пакетов, заполняя очередь полуоткрытых соединений. Это была одна из первых SYN flood-атак, которая привлекла внимание CERT.

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

Однако решения не пришлось долго ждать. Через неделю после атаки на PANIX Дэниел Бернштейн и Эрик Шенк предложили механизм SYN cookies. По нему, вместо того чтобы выделять память и создавать запись о полуоткрытом соединении для каждого SYN-пакета, сервер кодировал параметры соединения в TCP sequence number и отправлял клиенту SYN-ACK без сохранения состояния. 

Если клиент настоящий, он отвечал корректным ACK, после чего ядро восстанавливало состояние соединения. Если SYN был подделан или отправлен ботом, ответ не приходил, а значит, сервер не тратил ресурсы впустую.

Год спустя, в 1997-м, Гордон Лайон под псевдонимом Фёдор Васкович (отсылка к Достоевскому) выпустил Nmap — инструмент, который автоматизировал сетевую разведку. Этот сканер отправлял пакеты на разные порты и по ответам определял, какие сервисы доступны извне. 

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

К слову, в «Матрице: Перезагрузке» Тринити использует Nmap, находит открытый SSH на 22-м порту SCADA-системы и подключается к ней — это один из немногих технически правдоподобных моментов в голливудском кино. 

Уже тогда всем было понятно, что открытый порт — это потенциальная точка атаки, поэтому сисадмины начали массово переносить SSH с 22-го порта на нестандартные, снижая поток автоматических сканирований и брутфорса.

Однако и тут есть нюансы. Например, если перенести SSH, например, на 2222-й порт (зарегистрирован для Ethernet/IP-1), сервис окажется в диапазоне registered ports 1024–49151, где часть номеров уже закреплена за другими протоколами. Обычно это не создаёт проблем, но в корпоративных сетях возможны коллизии и вопросы от безопасников.

Что останется от «дверей»

Каждая инфраструктурная абстракция, которую инженеры считают вечной, рано или поздно превращается в деталь реализации. IP-адреса спрятались за DNS, диски — за volume managers, а порты постепенно растворяются в service discovery, mesh-сетях и бессерверке. Но до сих пор, когда что-то ломается, сисадмин открывает терминал и пишет ssh -p 22 или netstat -tlnp, чтобы проверить, кто занял восьмидесятый, или nmap -p-, чтобы убедиться, что предыдущий админ не оставил открытых дверей. 

Порты пережили NCP, TCP/IP и NAT, ведь они до гениальности просты — 16 бит, 65536 значений, и вся сложность интернета укладывается в это число. Думаю, они продолжат жить и через десятки лет…

Сколько портов открыто на вашем сервере прямо сейчас? Делитесь в комментариях, будет интересно сравнить.

© 2026 ООО «МТ ФИНАНС»