Module 2 → Lesson 9 → Part 6 of 8
Порты и сетевые сервисы
Lesson contents
What you'll learn
Одного IP-адреса недостаточно
У Emma Lee один ноутбук.
Но одновременно на нем работают:
- браузер;
- мессенджер;
- почтовая программа;
- облачное хранилище;
- VPN;
- другие приложения.
У всех них один и тот же сетевой интерфейс: ноутбук Emma с адресом 192.168.1.25.
Но данные приходят разные.
Как операционная система понимает:
этот сетевой обмен относится к браузеру, а этот — к другому приложению?
Для этого используются порты.
Что такое сетевой порт
Упрощенно: IP-адрес отвечает на вопрос, какое устройство, а port — на вопрос, какой сетевой сервис.
Это полезная модель для первого знакомства.
Порт — не физический разъем
У компьютера действительно могут быть физические порты: USB; HDMI; Ethernet.
Но TCP port 443 не является маленьким разъемом номер 443 внутри корпуса.
Сетевой порт — логическое число.
Он существует в программной сетевой модели.
Диапазон портов
В TCP и UDP номер порта занимает 16 бит.
Поэтому возможны номера от 0 до 65535.
То есть один компьютер потенциально может различать множество сетевых сервисов.
Но это не значит, что на каждом компьютере работают 65 536 приложений.
Большинство портов в конкретный момент вообще могут не использоваться.
TCP и UDP имеют свои порты
Это важная деталь.
Например, TCP 53 и UDP 53 — это не одно и то же транспортное взаимодействие.
Поэтому в сетевых правилах обычно недостаточно написать:
порт 53.
Нужно понимать еще и:
TCP или UDP?
Отсюда записи вроде TCP/443 или UDP/51820.
Сервер может «слушать» порт
Представим, что на сервере работает программа, ожидающая входящие сетевые соединения.
Она может сказать операционной системе:
«Если придет TCP-трафик на порт 443, передавай его мне».
Концептуально: трафик из Интернета приходит на IP сервера, попадает на TCP 443 и передается серверному приложению.
Так определенный порт становится связан с конкретным сетевым сервисом.
- 1TCP 22 → SSH service — сервис удаленного администрирования.
- 2TCP 443 → Web service — обычный веб-сервис.
- 3UDP 51820 → другой сетевой сервис — например, VPN.
- 4TCP 53 и UDP 53 — один и тот же номер порта, но разные транспортные протоколы, а значит и разные endpoints.
Что значит «порт открыт»
Эта фраза часто используется слишком свободно.
На базовом уровне полезно различать три вещи:
- программа действительно ожидает трафик на этом порту;
- операционная система позволяет ему попасть к программе;
- сетевые устройства по пути не блокируют такой обмен.
То есть наличие номера порта еще не означает:
сервис доступен из Интернета.
Пример
На сервере работает приложение на TCP 443.
Но firewall настроен: BLOCK TCP 443.
Приложение может быть запущено.
Но удаленный пользователь не сможет нормально к нему подключиться через этот путь.
Поэтому:
«сервис работает»
и:
«сервис доступен по сети»
— не совсем одно и то же.
Что такое firewall
Например: ALLOW TCP 443, BLOCK TCP 22, ALLOW UDP 51820.
Реальные правила могут учитывать гораздо больше параметров.
Но уже сейчас видно, почему нам понадобились предыдущие части курса:
протокол + адрес + порт = важные элементы сетевого правила.
Но зачем порт клиенту?
Теперь Emma открывает сайт.
Сервер может ждать соединение на известном порту, например 203.0.113.50:443.
Но Emma тоже должна получать ответы.
У нее ведь одновременно открыто множество сетевых соединений.
Поэтому ее компьютер выбирает собственный временный исходный порт, например 192.168.1.25:53142, для соединения с 203.0.113.50:443.
Что происходит с ответом
Сервер отвечает: с 203.0.113.50:443 на 192.168.1.25:53142.
Операционная система Emma видит:
этот ответ относится к соединению, использующему локальный порт 53142.
И передает данные нужному приложению.
- 1Emma (192.168.1.25:53142) отправляет запрос через TCP серверу 203.0.113.50:443.
- 2Сервер отвечает с 203.0.113.50:443 обратно на 192.168.1.25:53142 — по IP и порту операционная система Emma узнает, какому сетевому обмену принадлежит ответ.
Временные клиентские порты
Такие порты часто называют ephemeral ports — временные порты.
Пользователь обычно не выбирает его вручную.
Операционная система делает это автоматически.
Один браузер может иметь много соединений
Emma открыла несколько вкладок.
Браузер может одновременно использовать разные сетевые соединения, например: 192.168.1.25:53142 → Server A:443, 192.168.1.25:53143 → Server B:443, 192.168.1.25:53144 → Server C:443.
На удаленной стороне порт может быть одинаковым.
На клиентской стороне используются разные временные порты.
Так система различает соединения.
Соединение определяется не одним портом
Представлять соединение просто как «порт 443» слишком грубо.
TCP-соединение можно идентифицировать комбинацией: IP-адреса источника; порта источника; IP-адреса назначения; порта назначения.
И, конечно, транспортного протокола.
Концептуально: TCP-соединение 192.168.1.25:53142 → 203.0.113.50:443.
Это позволяет одновременно существовать огромному количеству независимых соединений.
Один и тот же сервер обслуживает множество клиентов
Представим сервер 203.0.113.50:443.
К нему одновременно подключаются: Emma, Alex, Sofia и Daniel — все на 203.0.113.50:443.
Серверный порт один.
Соединения разные.
Потому что у них различаются адреса и порты клиентов.
Некоторые порты стали стандартными
Со временем определенные сервисы начали традиционно использовать известные номера портов.
Например:
| Порт | Типичное назначение |
|---|---|
| TCP 22 | SSH |
| TCP 80 | HTTP |
| TCP 443 | HTTPS |
| UDP/TCP 53 | DNS |
Это стандартные соглашения, а не физический закон.
Программу технически можно запустить и на другом порту.
Например, сайт может работать на 8443
Разработчик может запустить веб-сервис по адресу https://example.com:8443.
Здесь явно указан порт 8443.
Если порт не указан в адресе, приложение обычно использует стандартное значение для соответствующего протокола.
Поэтому порт не определяет содержимое магически
Если программа слушает TCP 443, это еще не математическое доказательство:
«здесь обязательно правильный HTTPS-сервис».
Номер порта — соглашение и часть сетевой конфигурации.
Содержимое и протокол приложения определяются реальной программой и обменом.
Порт 443 не означает «сайт безопасный»
Это особенно важно.
Даже если соединение использует типичный HTTPS-порт TCP/443, это само по себе не означает:
- что сайт честный;
- что компания надежная;
- что пользователь находится на нужном домене;
- что деньги можно безопасно переводить.
Позже мы отдельно разберем HTTPS.
Но уже сейчас полезно разделить:
защищенное соединение
и:
доверие к тому, с кем установлено соединение.
Порты особенно важны для серверов
Если Emma просто открывает сайты, операционная система многое делает автоматически.
Но если Daniel настраивает собственный сервер, ему нужно решить:
- какой сервис запущен;
- какой порт он использует;
- должен ли сервис принимать внешние соединения;
- какие firewall rules разрешают доступ.
Например: SSH работает через TCP 22.
Если сервер администрируется удаленно, этот сервис может быть нужен.
Но открывать ненужные сетевые сервисы «на всякий случай» — плохая привычка.
Чем меньше ненужных сервисов, тем лучше
Каждый доступный сетевой сервис:
- состоит из программного кода;
- может иметь ошибки;
- требует настройки;
- может стать целью атак.
Поэтому один из базовых принципов безопасности:
не предоставлять сетевой доступ к тому, что не требуется.
Если сервис не нужен извне, обычно нет причин делать его доступным всему Интернету.
Это называется уменьшением поверхности атаки
Например, Server A держит открытыми TCP 22, TCP 80, TCP 443, TCP 3306 и TCP 6379, а Server B — только TCP 443.
Это не означает автоматически, что Server B безопасен.
Но у него потенциально меньше открытых сетевых точек взаимодействия.
«Закрыть порт» — не универсальное лечение
Здесь тоже нужна точность.
Если у приложения есть уязвимость, но сервис действительно нужен, решение:
«закрыть вообще все»
может сделать систему очень безопасной и одновременно совершенно бесполезной.
Задача безопасности:
разрешить необходимые взаимодействия и ограничить ненужные.
Firewall работает не только с портами
Упрощенно мы видим правило вроде ALLOW TCP 443.
Но реальные firewall могут учитывать:
- source IP;
- destination IP;
- protocol;
- source port;
- destination port;
- состояние соединения;
- сетевой интерфейс;
- направление трафика.
Например, «ALLOW TCP 22 FROM trusted network» может быть значительно разумнее, чем «ALLOW TCP 22 FROM everywhere», если удаленный доступ нужен только из определенной сети.
Stateful firewall
Современные межсетевые экраны часто умеют отслеживать состояние соединений.
Например, Emma сама установила исходящее TCP-соединение к серверу.
Firewall может понять, что обратные пакеты от сервера к Emma относятся к уже разрешенному соединению.
Это гораздо удобнее, чем вручную открывать случайный клиентский порт для каждого ответа.
Теперь вспомним NAT
В Части 2 у нас было: ноутбук 192.168.1.25 и телефон 192.168.1.26 через роутер выходят в Интернет.
Но если несколько внутренних устройств используют один внешний IPv4-адрес, роутеру нужно различать их соединения.
И здесь порты снова очень полезны.
Адреса плюс порты
Упрощенно роутер может отслеживать: 192.168.1.25:53142 как внешнее соединение A, а 192.168.1.26:49821 как внешнее соединение B.
Так ответы возвращаются нужному внутреннему устройству.
В бытовой речи это часто просто называют NAT.
Технически здесь могут использоваться преобразования не только адресов, но и портов.
А входящее соединение сложнее
Emma запускает сервер внутри домашней сети на 192.168.1.25:8080.
Удаленный пользователь в Интернете не может автоматически знать:
какому внутреннему устройству роутер должен передать новое входящее соединение.
Для этого может потребоваться специальное правило — port forwarding.
Что такое port forwarding
Например: внешний порт 8080 на домашнем роутере перенаправляется на 192.168.1.25:8080.
Это позволяет сделать внутренний сервис доступным извне.
Но port forwarding — это и вопрос безопасности
Если раньше внутренний сервис был недоступен напрямую из Интернета, а затем мы открыли 0.0.0.0/0 на TCP 8080 к внутреннему серверу, мы изменили поверхность атаки.
Поэтому перед открытием входящего доступа полезно спросить:
- Этот сервис действительно должен быть доступен извне?
- Он нормально защищен?
- Можно ли ограничить источники подключения?
- Нужно ли использовать VPN вместо прямого открытия сервиса?
И снова CGNAT
Если провайдер использует CGNAT, пользователь может столкнуться с ситуацией:
port forwarding на домашнем роутере настроен правильно, но входящий доступ из Интернета все равно не работает.
Почему?
Потому что перед домашним роутером существует еще один NAT у провайдера: Интернет → Provider NAT → домашний роутер → внутренний сервер.
Домашний пользователь не контролирует внешний NAT провайдера.
Это хороший пример того, почему для диагностики полезно понимать всю цепочку, а не только одну коробку дома.
Что такое socket
Теперь можно добавить еще одно полезное слово.
Упрощенно: приложение работает через socket, который взаимодействует с TCP или UDP, а те — с IP.
Для пользователя слово «socket» редко необходимо.
Для разработчика или администратора — встречается постоянно.
«Сервис слушает порт»
Теперь эта фраза становится понятнее.
Например: приложение открывает TCP socket на локальном порту 443 и переходит в состояние LISTEN.
То есть программа зарегистрировала сетевую точку, через которую ожидает соответствующие входящие соединения.
Но LISTEN еще не означает «доступно со всего мира»
Между клиентом и сервисом могут находиться: клиент, локальный firewall, роутер, провайдер, облачный firewall, серверный firewall и само приложение.
Достаточно одного блокирующего правила — и соединение не пройдет.
Поэтому диагностика:
«Приложение слушает порт, почему я не подключаюсь?»
может потребовать проверки нескольких уровней.
- 1Client отправляет запрос к серверу.
- 2Cloud firewall — сценарий A: если здесь BLOCK, трафик до сервиса вообще не доходит.
- 3Server firewall и сам сервис — сценарий B: даже если firewall пропускает трафик, сервис может не слушать нужный порт, и принимать соединение некому.
- 4Сценарий C: firewall разрешает трафик, и сервис слушает порт — сетевой путь к сервису существует.
Пример из жизни
На сервере запущен сервис на UDP 51820.
Программа действительно работает.
Но облачный firewall разрешает только TCP 22 и TCP 443.
Пакеты UDP/51820 не доходят до сервера.
Проблема не обязательно в приложении.
Она может находиться:
до него.
Это ровно та модель мышления, которую нам нужно сформировать.
Как читать правило firewall
Теперь запись «ALLOW UDP 51820 FROM 0.0.0.0/0» можно прочитать:
разрешить входящий UDP-трафик на порт 51820 от IPv4-источников из указанного диапазона.
А «ALLOW TCP 443» означает уже другой транспортный протокол и другой сервисный порт.
Эти правила нельзя считать взаимозаменяемыми только потому, что номер порта выглядит похожим.
Почему это пригодится в криптомире
Позже мы столкнемся с: blockchain nodes; RPC services; wallet connections; VPN; hardware and software wallets; exchange APIs.
Все это работает поверх обычных компьютерных сетей.
Криптография может быть необычной.
Но пакет все равно должен найти:
адрес
и:
нужный сетевой сервис.
Bitcoin не отменил TCP/IP.
Ethereum тоже решил не спорить с этой частью реальности.
Главное, что нужно запомнить
- IP-адреса помогают доставлять трафик устройствам и сетевым интерфейсам, а порты помогают различать сетевые приложения и сервисы.
- Сетевой порт — логический числовой идентификатор, а не физический разъем.
- TCP и UDP имеют собственные пространства портов.
- Серверное приложение может ожидать входящие соединения или датаграммы на определенном порту.
- Клиент обычно использует временный исходный порт, выбранный операционной системой.
- Сетевой обмен определяется не одним портом, а комбинацией адресов, портов и транспортного протокола.
- Некоторые номера портов традиционно связаны с известными сервисами, но это соглашение, а не гарантия содержимого.
- TCP/443 сам по себе не означает, что сайт безопасен или заслуживает доверия.
- Firewall разрешает или блокирует сетевой обмен по заданным правилам.
- Stateful firewall может учитывать состояние уже установленного соединения.
- Port forwarding делает внутренний сервис доступным через входящее правило и тем самым может увеличить поверхность атаки.
- CGNAT способен препятствовать прямому входящему подключению даже при правильной настройке домашнего роутера.
- Чем меньше ненужных сетевых сервисов доступно извне, тем меньше потенциальная поверхность атаки.
- Если приложение слушает порт, это еще не гарантирует, что трафик способен дойти до него через все промежуточные firewall и сети.
Что дальше
Мы уже разобрали: локальную сеть; IP; пакеты; маршрутизацию; TCP и UDP; порты.
Но в примерах постоянно появляются слова:
сервер
дата-центр
облако
Что между ними общего?
Где физически находится «облачное» приложение?
Может ли один физический сервер обслуживать множество систем?
И почему фраза:
«данные находятся в облаке»
не означает, что они действительно парят где-то над Атлантикой?
Продолжаем — в следующей части — «Клиент, сервер, дата-центр и «облако»».
- IP-адреса помогают доставлять трафик устройствам и сетевым интерфейсам, а порты помогают различать сетевые приложения и сервисы.
- Сетевой порт — логический числовой идентификатор, а не физический разъем.
- TCP и UDP имеют собственные пространства портов.
- Серверное приложение может ожидать входящие соединения или датаграммы на определенном порту.
- Клиент обычно использует временный исходный порт, выбранный операционной системой.
- Сетевой обмен определяется не одним портом, а комбинацией адресов, портов и транспортного протокола.
- Некоторые номера портов традиционно связаны с известными сервисами, но это соглашение, а не гарантия содержимого.
- TCP/443 сам по себе не означает, что сайт безопасен или заслуживает доверия.
- Firewall разрешает или блокирует сетевой обмен по заданным правилам.
- Stateful firewall может учитывать состояние уже установленного соединения.
- Port forwarding делает внутренний сервис доступным через входящее правило и тем самым может увеличить поверхность атаки.
- CGNAT способен препятствовать прямому входящему подключению даже при правильной настройке домашнего роутера.
- Чем меньше ненужных сетевых сервисов доступно извне, тем меньше потенциальная поверхность атаки.
- Если приложение слушает порт, это еще не гарантирует, что трафик способен дойти до него через все промежуточные firewall и сети.
One IP address is not enough
Emma Lee has one laptop.
But at the same time it's running:
- a browser;
- a messenger;
- a mail program;
- cloud storage;
- a VPN;
- other applications.
All of them share the same network interface: Emma's laptop with the address 192.168.1.25.
But the data arriving is different.
How does the operating system understand:
which network exchange belongs to the browser, and which one to a different application?
Ports are used for this.
What a network port is
Simplified: the IP address answers the question of which device, and the port answers the question of which network service.
This is a useful model for a first introduction.
A port is not a physical connector
A computer really can have physical ports: USB; HDMI; Ethernet.
But TCP port 443 is not a small connector numbered 443 inside the case.
A network port is a logical number.
It exists within the software network model.
The range of ports
In TCP and UDP the port number occupies 16 bits.
So numbers from 0 to 65535 are possible.
That means one computer can potentially distinguish a great many network services.
But that doesn't mean 65,536 applications are running on every computer.
Most ports at any given moment aren't being used at all.
TCP and UDP have their own ports
This is an important detail.
For example, TCP 53 and UDP 53 are not the same transport interaction.
That's why in network rules it's usually not enough to write:
port 53.
You also need to know:
TCP or UDP?
Hence notations like TCP/443 or UDP/51820.
A server can "listen" on a port
Imagine a program running on a server, waiting for incoming network connections.
It can tell the operating system:
"If TCP traffic arrives on port 443, pass it to me."
Conceptually: traffic from the Internet arrives at the server's IP, lands on TCP 443, and is passed to the server application.
That way a given port becomes associated with a specific network service.
- 1TCP 22 → SSH service — a remote administration service.
- 2TCP 443 → Web service — an ordinary web service.
- 3UDP 51820 → another network service — a VPN, for example.
- 4TCP 53 and UDP 53 — the same port number, but different transport protocols, and therefore different endpoints.
What "port is open" means
This phrase is often used too loosely.
At a basic level, it's useful to distinguish three things:
- a program is actually waiting for traffic on that port;
- the operating system lets that traffic reach the program;
- network devices along the path don't block that exchange.
In other words, the presence of a port number doesn't by itself mean:
the service is reachable from the Internet.
An example
An application on the server is running on TCP 443.
But the firewall is configured: BLOCK TCP 443.
The application may be up and running.
But a remote user won't be able to connect to it normally through this path.
So:
"the service works"
and:
"the service is reachable over the network"
— are not quite the same thing.
What a firewall is
For example: ALLOW TCP 443, BLOCK TCP 22, ALLOW UDP 51820.
Real-world rules can take into account far more parameters.
But already it's clear why we needed the previous parts of the course:
protocol + address + port = the important elements of a network rule.
But why does the client need a port?
Now Emma opens a website.
The server may be waiting for a connection on a known port, for example 203.0.113.50:443.
But Emma also needs to receive responses.
After all, she has many network connections open at the same time.
So her computer chooses its own temporary source port, for example 192.168.1.25:53142, for the connection to 203.0.113.50:443.
What happens with the response
The server responds: from 203.0.113.50:443 to 192.168.1.25:53142.
Emma's operating system sees:
this response belongs to the connection using local port 53142.
And passes the data to the correct application.
- 1Emma (192.168.1.25:53142) sends a request over TCP to the server 203.0.113.50:443.
- 2The server responds from 203.0.113.50:443 back to 192.168.1.25:53142 — by IP and port, Emma's operating system knows which network exchange the response belongs to.
Temporary client ports
Such ports are often called ephemeral ports.
The user usually doesn't choose it manually.
The operating system does this automatically.
A single browser can have many connections
Emma has opened several tabs.
The browser can use several network connections at the same time, for example: 192.168.1.25:53142 → Server A:443, 192.168.1.25:53143 → Server B:443, 192.168.1.25:53144 → Server C:443.
On the remote side, the port may be the same.
On the client side, different temporary ports are used.
That's how the system distinguishes between connections.
A connection is not defined by one port alone
Picturing a connection simply as "port 443" is too crude.
A TCP connection can be identified by the combination of: source IP address; source port; destination IP address; destination port.
And, of course, the transport protocol.
Conceptually: the TCP connection 192.168.1.25:53142 → 203.0.113.50:443.
This allows a huge number of independent connections to exist at the same time.
One and the same server serves many clients
Imagine the server 203.0.113.50:443.
Emma, Alex, Sofia, and Daniel all connect to it at the same time — all to 203.0.113.50:443.
The server port is one.
The connections are different.
Because the clients' addresses and ports differ.
Some ports have become standard
Over time, certain services traditionally began using well-known port numbers.
For example:
| Port | Typical purpose |
|---|---|
| TCP 22 | SSH |
| TCP 80 | HTTP |
| TCP 443 | HTTPS |
| UDP/TCP 53 | DNS |
These are standard conventions, not a law of physics.
A program can technically be run on a different port too.
For example, a website can run on 8443
A developer can run a web service at https://example.com:8443.
Here the port 8443 is stated explicitly.
If the port isn't specified in the address, the application usually uses the standard value for the corresponding protocol.
So a port doesn't magically define the content
If a program listens on TCP 443, that's still not mathematical proof that:
"there is necessarily a correct HTTPS service here."
A port number is a convention and part of the network configuration.
The application's content and protocol are determined by the actual program and exchange.
Port 443 doesn't mean "the site is safe"
This is especially important.
Even if a connection uses the typical HTTPS port TCP/443, that by itself does not mean:
- that the site is honest;
- that the company is reliable;
- that the user is on the correct domain;
- that money can safely be transferred.
Later we'll cover HTTPS separately.
But already it's useful to separate:
an encrypted connection
and:
trust in who the connection is established with.
Ports are especially important for servers
If Emma is just opening websites, the operating system handles a lot of this automatically.
But if Daniel is setting up his own server, he needs to decide:
- which service is running;
- which port it uses;
- whether the service should accept external connections;
- which firewall rules allow access.
For example: SSH runs over TCP 22.
If the server is administered remotely, this service may be needed.
But opening unnecessary network services "just in case" is a bad habit.
The fewer unnecessary services, the better
Every available network service:
- consists of program code;
- can have bugs;
- requires configuration;
- can become a target for attacks.
That's why one of the basic security principles is:
don't provide network access to what isn't required.
If a service isn't needed from the outside, there's usually no reason to make it available to the whole Internet.
This is called reducing the attack surface
For example, Server A keeps TCP 22, TCP 80, TCP 443, TCP 3306, and TCP 6379 open, while Server B keeps only TCP 443 open.
This doesn't automatically mean Server B is secure.
But it potentially has fewer open network points of interaction.
"Closing the port" is not a universal cure
Precision is needed here too.
If an application has a vulnerability but the service is genuinely needed, the decision to:
"close absolutely everything"
can make the system very secure and completely useless at the same time.
The task of security is:
allow the necessary interactions and restrict the unnecessary ones.
A firewall doesn't work with ports alone
In simplified form we see a rule like ALLOW TCP 443.
But real firewalls can take into account:
- source IP;
- destination IP;
- protocol;
- source port;
- destination port;
- connection state;
- network interface;
- direction of traffic.
For example, "ALLOW TCP 22 FROM trusted network" can be considerably more sensible than "ALLOW TCP 22 FROM everywhere," if remote access is only needed from a specific network.
Stateful firewall
Modern firewalls are often able to track the state of connections.
For example, Emma herself established an outgoing TCP connection to a server.
The firewall can recognize that return packets from the server to Emma belong to an already-allowed connection.
This is far more convenient than manually opening a random client port for every response.
Now let's recall NAT
In Part 2 we had: a laptop at 192.168.1.25 and a phone at 192.168.1.26 reaching the Internet through a router.
But if several internal devices use one external IPv4 address, the router needs to distinguish their connections.
And here ports are very useful again.
Addresses plus ports
Simplified, the router can track: 192.168.1.25:53142 as outbound connection A, and 192.168.1.26:49821 as outbound connection B.
That's how responses get returned to the correct internal device.
In everyday speech this is often simply called NAT.
Technically, this can involve translation of not just addresses but ports as well.
And an incoming connection is more complicated
Emma runs a server inside her home network at 192.168.1.25:8080.
A remote user on the Internet can't automatically know:
which internal device the router should hand a new incoming connection to.
This may require a special rule — port forwarding.
What port forwarding is
For example: external port 8080 on the home router is forwarded to 192.168.1.25:8080.
This makes it possible to make an internal service reachable from outside.
But port forwarding is also a matter of security
If previously the internal service was not directly reachable from the Internet, and then we opened 0.0.0.0/0 on TCP 8080 to the internal server, we've changed the attack surface.
So before opening incoming access, it's worth asking:
- Does this service really need to be reachable from outside?
- Is it properly protected?
- Can the sources allowed to connect be restricted?
- Should a VPN be used instead of directly opening the service?
And CGNAT again
If the provider uses CGNAT, a user might run into a situation where:
port forwarding on the home router is configured correctly, but incoming access from the Internet still doesn't work.
Why?
Because there's another NAT upstream of the home router, at the provider: Internet → Provider NAT → home router → internal server.
The home user does not control the provider's external NAT.
This is a good example of why, for diagnostics, it's useful to understand the whole chain, not just the one box at home.
What a socket is
Now we can add one more useful word.
Simplified: an application works through a socket, which interacts with TCP or UDP, and those in turn with IP.
For a user, the word "socket" is rarely necessary.
For a developer or administrator, it comes up constantly.
"The service is listening on the port"
Now this phrase becomes clearer.
For example: an application opens a TCP socket on local port 443 and enters the LISTEN state.
That is, the program has registered a network point through which it awaits the corresponding incoming connections.
But LISTEN still doesn't mean "reachable from the whole world"
Between the client and the service there can be: the client, a local firewall, a router, the provider, a cloud firewall, a server firewall, and the application itself.
A single blocking rule is enough, and the connection won't get through.
That's why the diagnostic question:
"The application is listening on the port, why can't I connect?"
may require checking several levels.
- 1The client sends a request to the server.
- 2Cloud firewall — scenario A: if there's a BLOCK here, the traffic never reaches the service at all.
- 3Server firewall and the service itself — scenario B: even if the firewall lets the traffic through, the service may not be listening on the needed port, and there's no one to accept the connection.
- 4Scenario C: the firewall allows the traffic, and the service is listening on the port — a network path to the service exists.
A real-life example
A service is running on the server on UDP 51820.
The program is genuinely working.
But the cloud firewall only allows TCP 22 and TCP 443.
UDP/51820 packets never reach the server.
The problem isn't necessarily in the application.
It can be located:
upstream of it.
This is exactly the way of thinking we need to build.
How to read a firewall rule
Now the entry "ALLOW UDP 51820 FROM 0.0.0.0/0" can be read as:
allow incoming UDP traffic on port 51820 from IPv4 sources within the specified range.
While "ALLOW TCP 443" means an entirely different transport protocol and a different service port.
These rules shouldn't be treated as interchangeable just because the port number looks similar.
Why this will be useful in the crypto world
Later we'll encounter: blockchain nodes; RPC services; wallet connections; VPN; hardware and software wallets; exchange APIs.
All of this runs on top of ordinary computer networks.
Cryptography can be unusual.
But a packet still has to find:
an address
and:
the right network service.
Bitcoin didn't abolish TCP/IP.
Ethereum also decided not to argue with this part of reality.
The main things to remember
- IP addresses help deliver traffic to devices and network interfaces, while ports help distinguish between network applications and services.
- A network port is a logical numeric identifier, not a physical connector.
- TCP and UDP have their own separate port spaces.
- A server application can wait for incoming connections or datagrams on a particular port.
- A client usually uses a temporary source port chosen by the operating system.
- A network exchange is defined not by one port alone, but by the combination of addresses, ports, and the transport protocol.
- Some port numbers are traditionally associated with well-known services, but that's a convention, not a guarantee of content.
- TCP/443 by itself doesn't mean a site is secure or trustworthy.
- A firewall allows or blocks network exchange according to defined rules.
- A stateful firewall can take into account the state of an already-established connection.
- Port forwarding makes an internal service reachable through an incoming rule and can thereby increase the attack surface.
- CGNAT can prevent a direct incoming connection even with a correctly configured home router.
- The fewer unnecessary network services reachable from outside, the smaller the potential attack surface.
- If an application is listening on a port, that still doesn't guarantee that traffic can reach it through all the intermediate firewalls and networks.
What's next
We've now covered: the local network; IP; packets; routing; TCP and UDP; ports.
But in the examples, certain words keep appearing:
server
data center
cloud
What do they have in common?
Where is a "cloud" application physically located?
Can a single physical server serve many systems?
And why doesn't the phrase:
"the data is in the cloud"
mean that it's actually floating somewhere over the Atlantic?
We continue — in the next part — "Client, server, data center, and the 'cloud'".
- IP addresses help deliver traffic to devices and network interfaces, while ports help distinguish network applications and services.
- A network port is a logical numeric identifier, not a physical connector.
- TCP and UDP each have their own port spaces.
- A server application can wait for incoming connections or datagrams on a specific port.
- A client usually uses a temporary source port chosen by the operating system.
- A network exchange is defined not by a port alone, but by a combination of addresses, ports, and the transport protocol.
- Some port numbers are traditionally associated with well-known services, but that's a convention, not a guarantee of content.
- TCP/443 by itself doesn't mean a site is safe or trustworthy.
- A firewall allows or blocks network traffic according to defined rules.
- A stateful firewall can factor in the state of an already-established connection.
- Port forwarding makes an internal service reachable via an inbound rule, and can thereby increase the attack surface.
- CGNAT can prevent direct inbound connections even when the home router is configured correctly.
- The fewer unnecessary network services exposed externally, the smaller the potential attack surface.
- If an application is listening on a port, that still doesn't guarantee traffic can reach it through every firewall and network along the way.
Μία διεύθυνση IP δεν αρκεί
Η Emma Lee έχει ένα laptop.
Αλλά ταυτόχρονα σε αυτό λειτουργούν:
- ένα πρόγραμμα περιήγησης·
- ένας messenger·
- ένα πρόγραμμα ηλεκτρονικού ταχυδρομείου·
- αποθηκευτικός χώρος στο cloud·
- VPN·
- άλλες εφαρμογές.
Όλες αυτές έχουν την ίδια δικτυακή διεπαφή: το laptop της Emma με διεύθυνση 192.168.1.25.
Όμως τα δεδομένα που φτάνουν είναι διαφορετικά.
Πώς καταλαβαίνει το λειτουργικό σύστημα:
αυτή η δικτυακή ανταλλαγή ανήκει στο πρόγραμμα περιήγησης, και αυτή σε μια άλλη εφαρμογή;
Για αυτό χρησιμοποιούνται οι θύρες.
Τι είναι μια δικτυακή θύρα
Απλοποιημένα: η διεύθυνση IP απαντά στην ερώτηση ποια συσκευή, ενώ η port απαντά στην ερώτηση ποια δικτυακή υπηρεσία.
Αυτό είναι ένα χρήσιμο μοντέλο για την πρώτη γνωριμία.
Η θύρα δεν είναι φυσική υποδοχή
Ένας υπολογιστής μπορεί όντως να έχει φυσικές θύρες: USB· HDMI· Ethernet.
Αλλά η TCP port 443 δεν είναι μια μικρή υποδοχή με τον αριθμό 443 μέσα στο περίβλημα.
Η δικτυακή θύρα είναι ένας λογικός αριθμός.
Υπάρχει μέσα στο λογισμικό δικτυακό μοντέλο.
Το εύρος των θυρών
Στα TCP και UDP, ο αριθμός της θύρας καταλαμβάνει 16 bit.
Γι' αυτό είναι δυνατοί αριθμοί από 0 έως 65535.
Δηλαδή ένας υπολογιστής μπορεί δυνητικά να διακρίνει πολλές δικτυακές υπηρεσίες.
Αλλά αυτό δεν σημαίνει ότι σε κάθε υπολογιστή λειτουργούν 65.536 εφαρμογές.
Οι περισσότερες θύρες σε μια συγκεκριμένη στιγμή μπορεί να μη χρησιμοποιούνται καθόλου.
Τα TCP και UDP έχουν τις δικές τους θύρες
Αυτή είναι μια σημαντική λεπτομέρεια.
Για παράδειγμα, TCP 53 και UDP 53 δεν είναι η ίδια αλληλεπίδραση μεταφοράς.
Γι' αυτό στους δικτυακούς κανόνες συνήθως δεν αρκεί να γράψουμε:
θύρα 53.
Χρειάζεται επίσης να καταλάβουμε:
TCP ή UDP;
Από εδώ προκύπτουν καταχωρίσεις όπως TCP/443 ή UDP/51820.
Ο διακομιστής μπορεί να «ακούει» μια θύρα
Ας φανταστούμε ότι σε έναν διακομιστή λειτουργεί ένα πρόγραμμα που περιμένει εισερχόμενες δικτυακές συνδέσεις.
Μπορεί να πει στο λειτουργικό σύστημα:
«Αν έρθει κίνηση TCP στη θύρα 443, δώσ' την σε εμένα».
Εννοιολογικά: η κίνηση από το Διαδίκτυο φτάνει στην IP του διακομιστή, καταλήγει στην TCP 443 και μεταβιβάζεται στην εφαρμογή του διακομιστή.
Έτσι μια συγκεκριμένη θύρα συνδέεται με μια συγκεκριμένη δικτυακή υπηρεσία.
- 1TCP 22 → SSH service — υπηρεσία απομακρυσμένης διαχείρισης.
- 2TCP 443 → Web service — συνηθισμένη υπηρεσία ιστού.
- 3UDP 51820 → μια άλλη δικτυακή υπηρεσία — για παράδειγμα, VPN.
- 4TCP 53 και UDP 53 — ο ίδιος αριθμός θύρας, αλλά διαφορετικά πρωτόκολλα μεταφοράς, άρα και διαφορετικά endpoints.
Τι σημαίνει «η θύρα είναι ανοιχτή»
Αυτή η φράση χρησιμοποιείται συχνά πολύ ελεύθερα.
Σε βασικό επίπεδο είναι χρήσιμο να διακρίνουμε τρία πράγματα:
- ένα πρόγραμμα πράγματι περιμένει κίνηση σε αυτή τη θύρα·
- το λειτουργικό σύστημα επιτρέπει να φτάσει σε αυτό το πρόγραμμα·
- οι δικτυακές συσκευές στη διαδρομή δεν εμποδίζουν αυτή την ανταλλαγή.
Δηλαδή η ύπαρξη ενός αριθμού θύρας δεν σημαίνει ακόμα:
η υπηρεσία είναι προσβάσιμη από το Διαδίκτυο.
Παράδειγμα
Σε έναν διακομιστή λειτουργεί μια εφαρμογή στην TCP 443.
Αλλά το firewall είναι ρυθμισμένο: BLOCK TCP 443.
Η εφαρμογή μπορεί να είναι εκτελούμενη.
Αλλά ο απομακρυσμένος χρήστης δεν θα μπορέσει να συνδεθεί κανονικά σε αυτήν μέσω αυτής της διαδρομής.
Γι' αυτό:
«η υπηρεσία λειτουργεί»
και:
«η υπηρεσία είναι προσβάσιμη μέσω δικτύου»
— δεν είναι ακριβώς το ίδιο πράγμα.
Τι είναι το firewall
Για παράδειγμα: ALLOW TCP 443, BLOCK TCP 22, ALLOW UDP 51820.
Οι πραγματικοί κανόνες μπορούν να λαμβάνουν υπόψη πολύ περισσότερες παραμέτρους.
Αλλά ήδη τώρα φαίνεται γιατί μας χρειάστηκαν τα προηγούμενα μέρη του μαθήματος:
πρωτόκολλο + διεύθυνση + θύρα = σημαντικά στοιχεία ενός δικτυακού κανόνα.
Αλλά γιατί χρειάζεται η θύρα στον πελάτη;
Τώρα η Emma ανοίγει έναν ιστότοπο.
Ο διακομιστής μπορεί να περιμένει σύνδεση σε μια γνωστή θύρα, για παράδειγμα 203.0.113.50:443.
Αλλά και η Emma πρέπει να λαμβάνει απαντήσεις.
Έχει άλλωστε ταυτόχρονα ανοιχτές πολλές δικτυακές συνδέσεις.
Γι' αυτό ο υπολογιστής της επιλέγει τη δική του προσωρινή θύρα προέλευσης, για παράδειγμα 192.168.1.25:53142, για τη σύνδεση με 203.0.113.50:443.
Τι συμβαίνει με την απάντηση
Ο διακομιστής απαντά: από 203.0.113.50:443 σε 192.168.1.25:53142.
Το λειτουργικό σύστημα της Emma βλέπει:
αυτή η απάντηση ανήκει στη σύνδεση που χρησιμοποιεί την τοπική θύρα 53142.
Και μεταβιβάζει τα δεδομένα στην κατάλληλη εφαρμογή.
- 1Η Emma (192.168.1.25:53142) στέλνει ένα αίτημα μέσω TCP στον διακομιστή 203.0.113.50:443.
- 2Ο διακομιστής απαντά από 203.0.113.50:443 πίσω στο 192.168.1.25:53142 — μέσω της IP και της θύρας το λειτουργικό σύστημα της Emma αναγνωρίζει σε ποια δικτυακή ανταλλαγή ανήκει η απάντηση.
Προσωρινές θύρες πελάτη
Τέτοιες θύρες συχνά ονομάζονται ephemeral ports — προσωρινές θύρες.
Ο χρήστης συνήθως δεν την επιλέγει χειροκίνητα.
Το λειτουργικό σύστημα το κάνει αυτό αυτόματα.
Ένα πρόγραμμα περιήγησης μπορεί να έχει πολλές συνδέσεις
Η Emma άνοιξε αρκετές καρτέλες.
Το πρόγραμμα περιήγησης μπορεί ταυτόχρονα να χρησιμοποιεί διαφορετικές δικτυακές συνδέσεις, για παράδειγμα: 192.168.1.25:53142 → Server A:443, 192.168.1.25:53143 → Server B:443, 192.168.1.25:53144 → Server C:443.
Στην απομακρυσμένη πλευρά η θύρα μπορεί να είναι ίδια.
Στην πλευρά του πελάτη χρησιμοποιούνται διαφορετικές προσωρινές θύρες.
Έτσι το σύστημα διακρίνει τις συνδέσεις.
Η σύνδεση δεν καθορίζεται από μία μόνο θύρα
Το να φανταζόμαστε τη σύνδεση απλώς ως «θύρα 443» είναι πολύ πρόχειρο.
Μια σύνδεση TCP μπορεί να αναγνωριστεί από τον συνδυασμό: της διεύθυνσης IP προέλευσης· της θύρας προέλευσης· της διεύθυνσης IP προορισμού· της θύρας προορισμού.
Και, φυσικά, του πρωτοκόλλου μεταφοράς.
Εννοιολογικά: η σύνδεση TCP 192.168.1.25:53142 → 203.0.113.50:443.
Αυτό επιτρέπει να υπάρχουν ταυτόχρονα τεράστιος αριθμός ανεξάρτητων συνδέσεων.
Ο ίδιος διακομιστής εξυπηρετεί πολλούς πελάτες
Ας φανταστούμε τον διακομιστή 203.0.113.50:443.
Σε αυτόν συνδέονται ταυτόχρονα: η Emma, ο Alex, η Sofia και ο Daniel — όλοι στο 203.0.113.50:443.
Η θύρα του διακομιστή είναι μία.
Οι συνδέσεις είναι διαφορετικές.
Επειδή διαφέρουν οι διευθύνσεις και οι θύρες των πελατών.
Ορισμένες θύρες έγιναν πρότυπες
Με τον καιρό, ορισμένες υπηρεσίες άρχισαν παραδοσιακά να χρησιμοποιούν γνωστούς αριθμούς θυρών.
Για παράδειγμα:
| Θύρα | Τυπική χρήση |
|---|---|
| TCP 22 | SSH |
| TCP 80 | HTTP |
| TCP 443 | HTTPS |
| UDP/TCP 53 | DNS |
Αυτές είναι πρότυπες συμβάσεις, όχι φυσικός νόμος.
Ένα πρόγραμμα μπορεί τεχνικά να εκτελεστεί και σε άλλη θύρα.
Για παράδειγμα, ένας ιστότοπος μπορεί να λειτουργεί στην 8443
Ένας προγραμματιστής μπορεί να εκτελέσει μια υπηρεσία ιστού στη διεύθυνση https://example.com:8443.
Εδώ αναφέρεται ρητά η θύρα 8443.
Αν η θύρα δεν αναφέρεται στη διεύθυνση, η εφαρμογή συνήθως χρησιμοποιεί την πρότυπη τιμή για το αντίστοιχο πρωτόκολλο.
Γι' αυτό η θύρα δεν καθορίζει μαγικά το περιεχόμενο
Αν ένα πρόγραμμα ακούει στην TCP 443, αυτό δεν είναι ακόμα μαθηματική απόδειξη ότι:
«εδώ σίγουρα υπάρχει σωστή υπηρεσία HTTPS».
Ο αριθμός θύρας είναι μια σύμβαση και μέρος της δικτυακής διαμόρφωσης.
Το περιεχόμενο και το πρωτόκολλο της εφαρμογής καθορίζονται από το πραγματικό πρόγραμμα και την ανταλλαγή.
Η θύρα 443 δεν σημαίνει «ο ιστότοπος είναι ασφαλής»
Αυτό είναι ιδιαίτερα σημαντικό.
Ακόμα και αν η σύνδεση χρησιμοποιεί την τυπική θύρα HTTPS TCP/443, αυτό από μόνο του δεν σημαίνει:
- ότι ο ιστότοπος είναι έντιμος·
- ότι η εταιρεία είναι αξιόπιστη·
- ότι ο χρήστης βρίσκεται στον σωστό τομέα (domain)·
- ότι τα χρήματα μπορούν να μεταφερθούν με ασφάλεια.
Αργότερα θα εξετάσουμε ξεχωριστά το HTTPS.
Αλλά ήδη τώρα είναι χρήσιμο να διαχωρίσουμε:
κρυπτογραφημένη σύνδεση
και:
εμπιστοσύνη προς αυτόν με τον οποίο έχει δημιουργηθεί η σύνδεση.
Οι θύρες είναι ιδιαίτερα σημαντικές για τους διακομιστές
Αν η Emma απλώς ανοίγει ιστότοπους, το λειτουργικό σύστημα κάνει πολλά αυτόματα.
Αλλά αν ο Daniel ρυθμίζει τον δικό του διακομιστή, πρέπει να αποφασίσει:
- ποια υπηρεσία εκτελείται·
- ποια θύρα χρησιμοποιεί·
- αν η υπηρεσία πρέπει να δέχεται εξωτερικές συνδέσεις·
- ποιοι κανόνες firewall επιτρέπουν την πρόσβαση.
Για παράδειγμα: το SSH λειτουργεί μέσω TCP 22.
Αν ο διακομιστής διαχειρίζεται εξ αποστάσεως, αυτή η υπηρεσία μπορεί να είναι απαραίτητη.
Αλλά το να ανοίγει κανείς περιττές δικτυακές υπηρεσίες «για κάθε ενδεχόμενο» είναι κακή συνήθεια.
Όσο λιγότερες περιττές υπηρεσίες, τόσο καλύτερα
Κάθε διαθέσιμη δικτυακή υπηρεσία:
- αποτελείται από κώδικα λογισμικού·
- μπορεί να έχει σφάλματα·
- απαιτεί ρύθμιση·
- μπορεί να γίνει στόχος επιθέσεων.
Γι' αυτό μία από τις βασικές αρχές ασφάλειας είναι:
να μην παρέχεται δικτυακή πρόσβαση σε ό,τι δεν χρειάζεται.
Αν μια υπηρεσία δεν χρειάζεται από έξω, συνήθως δεν υπάρχει λόγος να γίνει προσβάσιμη σε όλο το Διαδίκτυο.
Αυτό ονομάζεται μείωση της επιφάνειας επίθεσης
Για παράδειγμα, ο Server A κρατά ανοιχτές τις TCP 22, TCP 80, TCP 443, TCP 3306 και TCP 6379, ενώ ο Server B μόνο την TCP 443.
Αυτό δεν σημαίνει αυτόματα ότι ο Server B είναι ασφαλής.
Αλλά έχει δυνητικά λιγότερα ανοιχτά σημεία δικτυακής αλληλεπίδρασης.
Το «κλείσιμο μιας θύρας» δεν είναι καθολική θεραπεία
Και εδώ χρειάζεται ακρίβεια.
Αν μια εφαρμογή έχει μια ευπάθεια, αλλά η υπηρεσία είναι πράγματι απαραίτητη, η λύση:
«να κλείσουμε γενικά τα πάντα»
μπορεί να κάνει το σύστημα πολύ ασφαλές και ταυτόχρονα εντελώς άχρηστο.
Ο στόχος της ασφάλειας είναι:
να επιτρέπονται οι απαραίτητες αλληλεπιδράσεις και να περιορίζονται οι περιττές.
Το firewall δεν λειτουργεί μόνο με θύρες
Απλοποιημένα βλέπουμε έναν κανόνα όπως ALLOW TCP 443.
Αλλά τα πραγματικά firewall μπορούν να λαμβάνουν υπόψη:
- source IP·
- destination IP·
- protocol·
- source port·
- destination port·
- την κατάσταση της σύνδεσης·
- τη δικτυακή διεπαφή·
- την κατεύθυνση της κίνησης.
Για παράδειγμα, το «ALLOW TCP 22 FROM trusted network» μπορεί να είναι σημαντικά πιο λογικό από το «ALLOW TCP 22 FROM everywhere», αν η απομακρυσμένη πρόσβαση χρειάζεται μόνο από ένα συγκεκριμένο δίκτυο.
Stateful firewall
Τα σύγχρονα τείχη προστασίας συχνά μπορούν να παρακολουθούν την κατάσταση των συνδέσεων.
Για παράδειγμα, η Emma δημιούργησε η ίδια μια εξερχόμενη σύνδεση TCP προς έναν διακομιστή.
Το firewall μπορεί να καταλάβει ότι τα πακέτα απάντησης από τον διακομιστή προς την Emma ανήκουν σε μια ήδη επιτρεπόμενη σύνδεση.
Αυτό είναι πολύ πιο βολικό από το να ανοίγει κανείς χειροκίνητα μια τυχαία θύρα πελάτη για κάθε απάντηση.
Ας θυμηθούμε τώρα το NAT
Στο Μέρος 2 είχαμε: το laptop 192.168.1.25 και το τηλέφωνο 192.168.1.26 βγαίνουν στο Διαδίκτυο μέσω ενός router.
Αλλά αν πολλές εσωτερικές συσκευές χρησιμοποιούν μία κοινή εξωτερική διεύθυνση IPv4, ο router πρέπει να διακρίνει τις συνδέσεις τους.
Και εδώ οι θύρες είναι και πάλι πολύ χρήσιμες.
Διευθύνσεις συν θύρες
Απλοποιημένα, ο router μπορεί να παρακολουθεί: το 192.168.1.25:53142 ως εξωτερική σύνδεση A, και το 192.168.1.26:49821 ως εξωτερική σύνδεση B.
Έτσι οι απαντήσεις επιστρέφουν στην κατάλληλη εσωτερική συσκευή.
Στην καθημερινή γλώσσα αυτό συχνά ονομάζεται απλώς NAT.
Τεχνικά, εδώ μπορούν να χρησιμοποιούνται μετατροπές όχι μόνο διευθύνσεων, αλλά και θυρών.
Η εισερχόμενη σύνδεση είναι πιο περίπλοκη
Η Emma εκτελεί έναν διακομιστή μέσα στο οικιακό της δίκτυο στο 192.168.1.25:8080.
Ένας απομακρυσμένος χρήστης στο Διαδίκτυο δεν μπορεί αυτόματα να γνωρίζει:
σε ποια εσωτερική συσκευή πρέπει ο router να προωθήσει τη νέα εισερχόμενη σύνδεση.
Για αυτό μπορεί να χρειαστεί ένας ειδικός κανόνας — port forwarding.
Τι είναι το port forwarding
Για παράδειγμα: η εξωτερική θύρα 8080 στον οικιακό router προωθείται στο 192.168.1.25:8080.
Αυτό επιτρέπει να γίνει μια εσωτερική υπηρεσία προσβάσιμη από έξω.
Αλλά το port forwarding είναι και ζήτημα ασφάλειας
Αν παλαιότερα μια εσωτερική υπηρεσία δεν ήταν προσβάσιμη απευθείας από το Διαδίκτυο, και έπειτα ανοίξαμε το 0.0.0.0/0 στην TCP 8080 προς τον εσωτερικό διακομιστή, αλλάξαμε την επιφάνεια επίθεσης.
Γι' αυτό, πριν το άνοιγμα εισερχόμενης πρόσβασης, είναι χρήσιμο να αναρωτηθούμε:
- Αυτή η υπηρεσία πρέπει πράγματι να είναι προσβάσιμη από έξω;
- Είναι σωστά προστατευμένη;
- Μπορούν να περιοριστούν οι πηγές σύνδεσης;
- Χρειάζεται να χρησιμοποιηθεί VPN αντί για απευθείας άνοιγμα της υπηρεσίας;
Και πάλι το CGNAT
Αν ο πάροχος χρησιμοποιεί CGNAT, ο χρήστης μπορεί να αντιμετωπίσει την εξής κατάσταση:
το port forwarding στον οικιακό router είναι σωστά ρυθμισμένο, αλλά η εισερχόμενη πρόσβαση από το Διαδίκτυο εξακολουθεί να μη λειτουργεί.
Γιατί;
Επειδή πριν από τον οικιακό router υπάρχει ακόμα ένα NAT στον πάροχο: Διαδίκτυο → Provider NAT → οικιακός router → εσωτερικός διακομιστής.
Ο οικιακός χρήστης δεν ελέγχει το εξωτερικό NAT του παρόχου.
Αυτό είναι ένα καλό παράδειγμα του γιατί για τη διάγνωση είναι χρήσιμο να κατανοούμε ολόκληρη την αλυσίδα, όχι μόνο ένα κουτί στο σπίτι.
Τι είναι το socket
Τώρα μπορούμε να προσθέσουμε ακόμα μία χρήσιμη λέξη.
Απλοποιημένα: η εφαρμογή λειτουργεί μέσω ενός socket, το οποίο αλληλεπιδρά με το TCP ή το UDP, και αυτά με το IP.
Για τον χρήστη η λέξη «socket» σπάνια είναι απαραίτητη.
Για τον προγραμματιστή ή τον διαχειριστή — εμφανίζεται συνεχώς.
«Η υπηρεσία ακούει τη θύρα»
Τώρα αυτή η φράση γίνεται πιο κατανοητή.
Για παράδειγμα: η εφαρμογή ανοίγει ένα TCP socket στην τοπική θύρα 443 και περνά σε κατάσταση LISTEN.
Δηλαδή το πρόγραμμα κατέγραψε ένα δικτυακό σημείο, μέσω του οποίου περιμένει τις αντίστοιχες εισερχόμενες συνδέσεις.
Αλλά το LISTEN δεν σημαίνει ακόμα «προσβάσιμο από όλον τον κόσμο»
Ανάμεσα στον πελάτη και την υπηρεσία μπορεί να βρίσκονται: ο πελάτης, το τοπικό firewall, ο router, ο πάροχος, το firewall του cloud, το firewall του διακομιστή και η ίδια η εφαρμογή.
Αρκεί ένας μόνο κανόνας αποκλεισμού — και η σύνδεση δεν θα περάσει.
Γι' αυτό η διάγνωση:
«Η εφαρμογή ακούει τη θύρα, γιατί δεν μπορώ να συνδεθώ;»
μπορεί να απαιτήσει έλεγχο σε πολλά επίπεδα.
- 1Ο Client στέλνει ένα αίτημα στον διακομιστή.
- 2Cloud firewall — σενάριο A: αν εδώ υπάρχει BLOCK, η κίνηση δεν φτάνει καθόλου στην υπηρεσία.
- 3Server firewall και η ίδια η υπηρεσία — σενάριο B: ακόμα και αν το firewall αφήνει την κίνηση να περάσει, η υπηρεσία μπορεί να μην ακούει τη σωστή θύρα, και δεν υπάρχει κανείς να δεχτεί τη σύνδεση.
- 4Σενάριο C: το firewall επιτρέπει την κίνηση, και η υπηρεσία ακούει τη θύρα — υπάρχει δικτυακή διαδρομή προς την υπηρεσία.
Παράδειγμα από την πραγματική ζωή
Σε έναν διακομιστή εκτελείται μια υπηρεσία στην UDP 51820.
Το πρόγραμμα λειτουργεί πράγματι.
Αλλά το firewall του cloud επιτρέπει μόνο TCP 22 και TCP 443.
Τα πακέτα UDP/51820 δεν φτάνουν στον διακομιστή.
Το πρόβλημα δεν βρίσκεται απαραίτητα στην εφαρμογή.
Μπορεί να βρίσκεται:
πριν από αυτήν.
Αυτό είναι ακριβώς το μοντέλο σκέψης που χρειάζεται να διαμορφώσουμε.
Πώς να διαβάσουμε έναν κανόνα firewall
Τώρα η καταχώριση «ALLOW UDP 51820 FROM 0.0.0.0/0» μπορεί να διαβαστεί:
επίτρεψε την εισερχόμενη κίνηση UDP στη θύρα 51820 από πηγές IPv4 μέσα στο καθορισμένο εύρος.
Ενώ το «ALLOW TCP 443» σημαίνει ήδη διαφορετικό πρωτόκολλο μεταφοράς και διαφορετική θύρα υπηρεσίας.
Αυτοί οι κανόνες δεν μπορούν να θεωρηθούν εναλλάξιμοι μόνο επειδή ο αριθμός θύρας μοιάζει παρόμοιος.
Γιατί αυτό θα φανεί χρήσιμο στον κόσμο των κρυπτονομισμάτων
Αργότερα θα συναντήσουμε: blockchain nodes· RPC services· wallet connections· VPN· hardware and software wallets· exchange APIs.
Όλα αυτά λειτουργούν πάνω από τα συνηθισμένα δίκτυα υπολογιστών.
Η κρυπτογραφία μπορεί να είναι ασυνήθιστη.
Αλλά το πακέτο πρέπει και πάλι να βρει:
τη διεύθυνση
και:
τη σωστή δικτυακή υπηρεσία.
Το Bitcoin δεν κατάργησε το TCP/IP.
Το Ethereum επίσης αποφάσισε να μη διαφωνήσει με αυτό το κομμάτι της πραγματικότητας.
Το βασικό που πρέπει να θυμόμαστε
- Οι διευθύνσεις IP βοηθούν να παραδίδεται η κίνηση σε συσκευές και δικτυακές διεπαφές, ενώ οι θύρες βοηθούν να διακρίνονται οι δικτυακές εφαρμογές και υπηρεσίες.
- Η δικτυακή θύρα είναι ένας λογικός αριθμητικός αναγνωριστικός κωδικός, όχι φυσική υποδοχή.
- Τα TCP και UDP έχουν δικούς τους χώρους θυρών.
- Μια εφαρμογή διακομιστή μπορεί να περιμένει εισερχόμενες συνδέσεις ή datagrams σε συγκεκριμένη θύρα.
- Ο πελάτης συνήθως χρησιμοποιεί μια προσωρινή θύρα προέλευσης, επιλεγμένη από το λειτουργικό σύστημα.
- Η δικτυακή ανταλλαγή καθορίζεται όχι από μία μόνο θύρα, αλλά από τον συνδυασμό διευθύνσεων, θυρών και πρωτοκόλλου μεταφοράς.
- Ορισμένοι αριθμοί θυρών συνδέονται παραδοσιακά με γνωστές υπηρεσίες, αλλά αυτό είναι σύμβαση, όχι εγγύηση περιεχομένου.
- Το TCP/443 από μόνο του δεν σημαίνει ότι ο ιστότοπος είναι ασφαλής ή αξιόπιστος.
- Το firewall επιτρέπει ή εμποδίζει τη δικτυακή ανταλλαγή σύμφωνα με καθορισμένους κανόνες.
- Το Stateful firewall μπορεί να λαμβάνει υπόψη την κατάσταση μιας ήδη εγκατεστημένης σύνδεσης.
- Το Port forwarding κάνει μια εσωτερική υπηρεσία προσβάσιμη μέσω ενός κανόνα εισερχόμενης κίνησης και έτσι μπορεί να αυξήσει την επιφάνεια επίθεσης.
- Το CGNAT μπορεί να εμποδίσει την απευθείας εισερχόμενη σύνδεση ακόμα και με σωστά ρυθμισμένο τον οικιακό router.
- Όσο λιγότερες περιττές δικτυακές υπηρεσίες είναι διαθέσιμες από έξω, τόσο μικρότερη η δυνητική επιφάνεια επίθεσης.
- Αν μια εφαρμογή ακούει μια θύρα, αυτό δεν εγγυάται ακόμα ότι η κίνηση μπορεί να φτάσει σε αυτήν μέσα από όλα τα ενδιάμεσα firewall και δίκτυα.
Τι ακολουθεί
Έχουμε ήδη εξετάσει: το τοπικό δίκτυο· το IP· τα πακέτα· τη δρομολόγηση· τα TCP και UDP· τις θύρες.
Όμως στα παραδείγματα εμφανίζονται συνεχώς οι λέξεις:
διακομιστής
κέντρο δεδομένων
cloud
Τι κοινό έχουν μεταξύ τους;
Πού βρίσκεται φυσικά μια εφαρμογή «στο cloud»;
Μπορεί ένας φυσικός διακομιστής να εξυπηρετεί πολλά συστήματα;
Και γιατί η φράση:
«τα δεδομένα βρίσκονται στο cloud»
δεν σημαίνει ότι πράγματι αιωρούνται κάπου πάνω από τον Ατλαντικό;
Συνεχίζουμε — στο επόμενο μέρος — «Πελάτης, διακομιστής, κέντρο δεδομένων και «cloud»».
- Οι διευθύνσεις IP βοηθούν στην παράδοση κίνησης σε συσκευές και δικτυακές διεπαφές, ενώ οι θύρες βοηθούν να ξεχωρίζουμε τις δικτυακές εφαρμογές και υπηρεσίες.
- Η δικτυακή θύρα είναι ένας λογικός αριθμητικός αναγνωριστικός κωδικός, όχι φυσικός σύνδεσμος.
- Τα TCP και UDP έχουν το καθένα δικό του χώρο θυρών.
- Μια εφαρμογή διακομιστή μπορεί να περιμένει εισερχόμενες συνδέσεις ή datagrams σε μια συγκεκριμένη θύρα.
- Ένας πελάτης συνήθως χρησιμοποιεί μια προσωρινή θύρα προέλευσης που επιλέγει το λειτουργικό σύστημα.
- Μια δικτυακή ανταλλαγή δεν ορίζεται μόνο από μία θύρα, αλλά από τον συνδυασμό διευθύνσεων, θυρών και πρωτοκόλλου μεταφοράς.
- Ορισμένοι αριθμοί θυρών συνδέονται παραδοσιακά με γνωστές υπηρεσίες, αλλά αυτό είναι σύμβαση, όχι εγγύηση περιεχομένου.
- Το TCP/443 από μόνο του δεν σημαίνει ότι ένας ιστότοπος είναι ασφαλής ή αξιόπιστος.
- Ένα firewall επιτρέπει ή αποκλείει τη δικτυακή κίνηση σύμφωνα με καθορισμένους κανόνες.
- Ένα stateful firewall μπορεί να λάβει υπόψη την κατάσταση μιας ήδη καθιερωμένης σύνδεσης.
- Το port forwarding καθιστά μια εσωτερική υπηρεσία προσβάσιμη μέσω ενός εισερχόμενου κανόνα, και έτσι μπορεί να αυξήσει την επιφάνεια επίθεσης.
- Το CGNAT μπορεί να εμποδίσει τις άμεσες εισερχόμενες συνδέσεις ακόμη και όταν ο οικιακός δρομολογητής είναι σωστά ρυθμισμένος.
- Όσο λιγότερες περιττές δικτυακές υπηρεσίες είναι εκτεθειμένες προς τα έξω, τόσο μικρότερη η δυνητική επιφάνεια επίθεσης.
- Αν μια εφαρμογή ακούει σε μια θύρα, αυτό ακόμη δεν εγγυάται ότι η κίνηση μπορεί να τη φτάσει μέσα από όλα τα ενδιάμεσα firewall και δίκτυα.