Как использовать ssh туннель

Создание SSH-туннелей с помощью PuTTY

В данной статье будет описано как строить SSH–туннели с помощью PuTTY.

1. Локальный проброс порта

Рассмотрим следующую ситуацию. Мы находимся внутри корпоративной сети, у нашего компьютера адрес 192.168.0.2, доступ во внешний мир полностью закрыт (то есть никакого NAT–а, proxy и т.п.). Влиять на политику ограничения доступа у нас возможности нет, но зато есть SSH–доступ на один из серверов с маршрутизируемым IP–адресом, который доступен из Интернета. Внутренний адрес этого сервера, пусть будет для примера 192.168.0.3. Структура сети изображена на рисунке:

Предположим, что нам очень нужно подключиться, к примеру, по SSH на некоторый удалённый сервер с IP–адресом 212.212.212.212 где–то далеко в Интернет. Для этого запускаем PuTTY, создаём SSH–подключение к серверу 192.168.0.3 (далее по тексту SSH–сессия 1), идём в пункт Tunnels:

и указываем, что локальный порт 2222 нашего компьютера должен быть поставлен в соответствие порту 22 на сервере с IP–адресом 212.212.212.212. Далее жмём кнопку «Open», авторизуемся на сервере 192.168.0.3. Затем создаём ещё одно подключение (далее по тексту SSH–сессия 2), но уже на localhost, порт 2222 и жмём кнопку «Open»:

В результате SSH–сессия 2 будет туннелироваться (т.е. будет установлена внутри ранее установленной SSH–сессии 1). Для удалённого сервера 212.212.212.212 всё будет выглядеть так, как будто к нему подключается 111.111.111.111:

2. Удалённый проброс порта

В этом случае подключение внутри SSH–туннеля устанавливается в другую сторону — от удалённого сервера на наш локальный компьютер. Может быть полезно, если требуется открыть доступ к локальным сервисам нашего компьютера. Рассмотрим ту же сеть, что и в пункте 1, но для простоты предположим, что теперь у нас есть NAT:

Здесь уже у нас есть возможность подключаться через SSH напрямую к 212.212.212.212 благодаря наличию NAT–а. А вот 212.212.212.212 подключиться на 192.168.0.2 без специальных ухищрений, понятное дело, не сможет, т.к. 192.168.0.2 не подключён к Интернет непосредственно. Предположим, что пользователю, сидящему под X–ами на 212.212.212.212 нужно через remote desktop попасть на наш компьютер 192.168.0.2. Для этого в SSH–сеансе подключения с 192.168.0.2 на 212.212.212.212 нужно изменить настройки в разделе Tunnels следующим образом:

В результате после успешной авторизации на 212.212.212.212 можно увидеть следующее:

То есть sshd ожидает подключений на TCP–порт 3333, которые затем по SSH–туннелю будут перенаправлены на 192.168.0.2 порт 3389. И юзер сидящий за 212.212.212.212 сможет с помощью rdesktop увидеть наш рабочий стол:

3. Socks–proxy

В этом случае мы можем использовать сервер с SSH–демоном как промежуточный (proxy). Схема сети как в случае #1 (без NAT и штатных прокси):

Чтобы заставить PuTTY исполнять роль socks–прокси, нужно параметры SSH–сессии с 192.168.0.2 на 192.168.0.3 изменить следующим образом:

В результате после успешной авторизации со стороны клиента можно будет наблюдать следующее:

То есть putty, выполняющийся с PID–ом 2392, начинает слушать порт 1080, ожидая подключений. Далее бёрем любое приложение, умеющее работать с SOCKS–прокси, например Firefox, и указываем ему использовать наш прокси:

Теперь все запросы от браузера будут проходить через сервер 192.168.0.3. В логах веб–сайтов, по которым мы таким образом будем ходить, будет отображаться внешний IP–адрес нашего сервера — 111.111.111.111.

P.S. Из help–файла Putty 0.58:

Question A.10.3: What does «PuTTY» mean?

It’s the name of a popular SSH and Telnet client. Any other meaning is in the eye of the beholder. It’s been rumoured that «PuTTY» is the antonym of «getty», or that it’s the stuff that makes your Windows useful… 🙂

SSH Tunneling Explained

Although the typical use case of SSH is to access a remote server securely, you can also transfer files, forward local and remote ports, mount remote directories, redirect GUI, or even proxy arbitrary traffic (need I say SSH is awesome?). And this is just a small set of what's possible with SSH.

In this post, I'll cover different tunneling features as supported by OpenSSH, which helps achieve security use cases such as remote web service access without exposing ports on the internet, accessing servers behind NAT, exposing local ports to the internet. OpenSSH is the most widely used open-source SSH server. It comes pre-installed by default with the vast majority of Linux distributions.

If you are looking for a modern open-source alternative to OpenSSH that is optimized for elastic multi-cloud environments and supports other access protocols in addition to SSH, make sure to check out Teleport.

What is SSH tunneling?

SSH tunneling is a method to transport additional data streams within an existing SSH session. SSH tunneling helps achieve security use cases such as remote web service access without exposing port on the internet, accessing server behind NAT, exposing local port to the internet.

How does the SSH tunnel work?

When you connect to a server using SSH, you get a server's shell. This is the default behavior of an SSH connection. Under the hood, your SSH client creates an encrypted session between your SSH client and the SSH server. But the data transported within the SSH session can be of any type. For example, during shell access, the data transmitted are binary streams detailing dimensions of pseudo-terminal and ASCII characters to run commands on the remote shell. However, during SSH port forwarding, the data transmitted can be a binary stream of protocol tunneled over SSH (e.g. SQL over SSH).

So SSH tunneling is just a way to transport arbitrary data with a dedicated data stream (tunnel) inside an existing SSH session. This can be achieved with either local port forwarding, remote port forwarding, dynamic port forwarding, or by creating a TUN/TAP tunnel. Let's take a look at how port forwarding works and their use cases below.

Local port forwarding

When local port forwarding is used, OpenSSH creates a separate tunnel inside the SSH connection that forwards network traffic from the local port to the remote server's port. In OpenSSH, this tunneling feature can be used by supplying -L flag. Internally, SSH allocates a socket listener on the client on the given port. When a connection is made to this port, the connection is forwarded over the existing SSH channel over to the remote server's port.

Local port forwarding is one of the ways of securing an insecure protocol or making a remote service appear local.

When to use local port forwarding?

Accessing insecure protocol

If a service running at a remote server does not natively support an encrypted transport mechanism, in that case, local port forwarding can be used to connect to that service by tunneling inside an encrypted SSH session.

Secure access to remote service

For security reasons, it is good to bind services only to the local interface (as opposed to listening on a public interface). The flip side to this is how users would access the service from an external network. You can use local port forwarding to access the service that is listening on the remote localhost. In this way, connections on the local machine made to the forwarded port will, in effect, be connecting to the remote machine.

Consider an example below where PostgreSQL database on remote server listens on remote localhost ( 127.0.0.1:5432 ). There is no way the client can connect directly to this database but can access the server via SSH. So with SSH local port forwarding, the client connects to the remote server (with valid SSH credential) and commands SSH to forward the client's local port 5432 to the server's local port 5432 . Thus, when a program (pgAdmin in this case) connects to the port 5432 of the client, SSH forwards the connection to the local port 5432 of the remote server (running PostgreSQL).

SSH local port forwarding command for above scenario:

bash $ ssh -L 5432:127.0.0.1:5432 [email protected]<remote_db_server>

Further, there are no restrictions on the number of port forwarding you want to enable. For example, below SSH forwards two local ports, 3338 and 3339 , to remote ports 3338 and 3339 .

bash $ ssh -L 3338:localhost:3338 -L 3339:localhost:3339 [email protected]<remote_server>

By default, an interactive session is created for you when you command local port forwarding. To prevent interactive sessions, you can use the -N flag that tells SSH to not to execute remote commands:

bash $ ssh -N -L 3339:localhost:3339 [email protected]<remote_server>

Remote port forwarding (reverse tunneling)

Also often called SSH reverse tunneling, remote port forwarding redirects the remote server's port to the localhost's port. When remote port forwarding is used, at first, the client connects to the server with SSH. Then, SSH creates a separate tunnel inside the existing SSH session that redirects incoming traffic in the remote port to localhost (where SSH connection was created).

Remote port forwarding can be achieved in OpenSSH by using -R flag. Internally, SSH allocates a socket listener on the remote server on the given port. When a connection is made to this port, the connection is forwarded over the existing SSH channel over to the local client's port.

When to use remote port forwarding?

Exposing service running in localhost of a server behind NAT to the internet

Consider the scenario below. The client runs a web server on port 3000 but cannot expose this web server to the public internet as the client machine is behind NAT. The remote server, on the other hand, can be reachable via the internet. The client can SSH into this remote server. In this situation, how can the client expose the webserver on port 3000 to the internet? Via reverse SSH tunnel!

Steps:

1. Run a web server on client localhost port 3000 . 2. Configure reverse tunnel with command.

bash $ ssh -R 80:127.0.0.1:3000 [email protected]<remote_server_ip>

1. Now, when users from distant internet visit port 80 of the remote server as http://<remote_server_ip> , the request is redirected back to the client's local server (port 3000 ) via SSH tunnel where the local server handles the request and response.

By default, the remote port forwarding tunnel will bind to the localhost of the remote server. To enable it to listen on the public interface (for a scenario like above), set the SSH configuration GatewayPorts yes in sshd_config .

Alternative to local port forwarding

Local port forwarding does not work if incoming SSH requests in the remote server are disabled. For security reasons, administrators might entirely block inbound SSH requests but allow outbound SSH requests. In such situations, you can use remote port forwarding to create an outbound SSH connection and let the clients connect to the local port even if inbound connections are blocked.

Dynamic port forwarding

Both local and remote port forwarding require defining a local and remote port. What if the ports are unknown beforehand or if you want to relay traffic to an arbitrary destination? Also known as dynamic tunneling, or SSH SOCKS5 proxy, dynamic port forwarding allows you to specify a connect port that will forward every incoming traffic to the remote server dynamically.

Dynamic port forwarding turns your SSH client into a SOCKS5 proxy server. SOCKS is an old but widely used protocol for programs to request outbound connections through a proxy server.

When to use dynamic port forwarding?

Bypassing content filters

By tunneling network traffic inside SSH, it is possible to access services such as HTTP web pages that may be blocked by your ISP or organization. SOCKS5 proxy can proxy any type of traffic and any type of protocol. This means you can tunnel HTTP inside SSH using SOCKS5.

Consider the case above. The client cannot access certain web pages due to content filtering implemented in front by the firewall. But the client can connect to the remote server (via SSH), which has unrestricted access to the internet. In this case, the client can initiate ssh connection by enabling dynamic port forwarding, thus creating a SOCKS5 proxy; the client can point web browser to proxy listening on local port 6000 and access restricted web content.

Command used for dynamic SSH tunneling scenario above:

SSH TUN/TAP tunneling

SSH supports tunnel device forwarding (also known as TUN/TAP). TUN/TAP are virtual network interfaces that can be used to create a tunnel between two servers. This setup is a poor man's VPN. For a fully working SSH-forwarded TUN/TAP tunnel, you will first need to add a tun device and configure routing between two servers. The format for using SSH TUN is -w local_tun[:remote_tun] . Refer to this guide for a complete setup. There's also a script available in this blog post if you want to try tunneling in your server.

Bonus — SSH tunnel over TOR

So far, we've discussed how SSH supports tunneling inside existing SSH sessions. But SSH itself can be tunneled over other protocols such as SOCKS. TOR is a popular anonymity software that supports tunneling any protocol over its SOCKS5 proxy.

SSH already provides a secure way of communicating via encrypted channels. If you want additional anonymity (conceal origin of SSH session), you can use TOR to relay SSH connection. This can be done by using torsocks as:

bash $ ssh -o ProxyCommand="nc -X 5 -x localhost:9050 %h %p" [email protected]<remote_server>

Security concerns of SSH tunneling

So far, we have covered the advantages of SSH tunneling and how it makes it easy to connect to remote services, which otherwise would not be possible due to network configurations and restrictions. But this power of SSH tunneling is also often misused by malicious users. Hiding malicious traffic within an SSH tunnel is a common classic way to go undetected inside a network. For example, read this post where android malware used SSH tunnel to access corporate network, this report which states Fox Kitten campaign using SSH tunnel, or this article describing misuse of SSH tunnels to send spam.

Detecting such activities is tough since SSH communications are encrypted, and you would not know what kind of data is transported underneath. If you are a network or security administrator, a continuous full traffic analysis within your network is a must which might give you clues such as types of SSH access performed, e.g., SSH file transfer, SSH shell access, or SSH tunnel. If the patterns do not match the work stuff that SSH requires to be used within your network, it might be a good lead to start an investigation.

Teleport cybersecurity blog posts and tech news

Every other week we'll send a newsletter with the latest cybersecurity news and Teleport updates.

Conclusion

Although the default behavior of an SSH server is to return a remote server's shell over an encrypted channel, SSH supports sending and receiving binary data over SSH. Transporting arbitrary data streams over SSH sessions is also known as SSH tunneling. OpenSSH, a popular open-source SSH server, supports three types of tunneling features- local port forwarding, remote port forwarding, and dynamic port forwarding. These tunneling features help achieve security use cases such as remote web service access without exposing port 443 on the internet, accessing server behind NAT, exposing local port to the internet, or even create a point-to-point VPN like encrypted tunnel.

SSH tunneling techniques are also frequently used by adversaries to hide malicious network traffics. As a network or security administrator, if your team or developers use an SSH tunnel, it is important to monitor traffic patterns to continuously detect anomalies in regular patterns. This can be done by first capturing packets with packet sniffing tools such as tcpdump and Wireshark and analyzing the traffic.

Next — Try Teleport. Teleport is a modern SSH server with features optimized for elastic multi-cloud environments and supports other access protocols in addition to SSH. If your servers are split across different networks/clouds, Teleport Node Tunneling lets you manage secure remote access without the need to open these servers to the public network.

Настройка SSH-туннелирования на VPS

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

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

Теория: Cвязь в Интернете, сетевые протоколы и порты

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

• HTTP используется для загрузки веб-сайтов и файлов в веб-браузере.
• FTP используется для отправки файлов между клиентом и сервером.
• DNS используется для преобразования имени хоста в IP-адрес и наоборот.
• POP3 и (или) IMAP предназначены для загрузки и просмотра электронной почты.
• SMTP используется для отправки электронной почты.
• telnet предназначен для удаленного подключения к серверу.
• SSH похож на telnet, но это его безопасная, зашифрованная версия (благодаря этому никто не может видеть передаваемые данные).

Затем сообщения данного протокола должны быть упакованы в сегмент TCP или UDP-дейтаграмму (на транспортном уровне). Эти протоколы используются для передачи данных через Интернет – они работают на транспортном уровне. Протокол TCP является протоколом с установлением соединения, а это означает, что перед отправкой данных между удаленными машинами требуется создать соединение. TCP всегда предоставляет данные в правильном порядке. Если какой-либо сегмент будет потерян во время передачи по сети, он будет отправлен снова. TCP считается достаточно надежным протоколом.

UDP является протоколом без установления соединения. Он не обеспечивает повторную передачу потерянных дейтаграмм. Если пакеты не были получены в правильном порядке, UDP все равно будет передавать их в приложение в том порядке, в котором он их получил. Из-за этого UDP в основном используется для передачи мультимедийных данных в реальном времени – переговоров по VoIP, видеоконференций, аудио и видео. UDP иногда используется другими протоколами на прикладном уровне – например, в случае DNS.

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

Чтобы идентифицировать разные соединения с одним и тем же IP-адресом, используются номера портов. Каждый сервер данного протокола прикладного уровня связывается с определенным номером порта и ожидает входящего соединения. Клиент подключается к этому порту (в случае TCP-соединения) или отправляет на этот порт дейтаграмму (в случае UDP). Для наиболее часто используемых протоколов есть зарезервированные номера портов. Например, HTTP-сервер обычно прослушивает порт 80 TCP (в некоторых случаях клиенты должны указывать номер порта в адресе – http://example.org:1234/), DNS-сервер обычно прослушивает порт 53 UDP (иногда 53 TCP). Клиент также должен использовать порт на своей стороне. Они генерируются случайным образом.

Здесь вы можете просмотреть список зарезервированных портов, которые вы используете каждый день.

Сегменты и дейтаграммы затем упаковываются в IP-пакеты на сетевом уровне. В пакетах исходный и целевой компьютер идентифицируются по IP-адресам. Они глобальны – только один хост может использовать один и тот же адрес за раз (за исключением NAT, что используется в домашних маршрутизаторах с частными IP-адресами: 192.168.xx, 10.xxx, 172.16-31.xx; где x – число от 1 и 255). На основе этих адресов маршрутизаторы могут решить, как отправить пакет на целевой компьютер.

Затем пакеты упаковываются в ячейки на канальном уровне, а затем передаются по кабелю или в виде радиоволн в локальной сети. На канальном уровне компьютеры идентифицируются по их MAC-адресам. Ячейки с MAC-адресами полностью удаляются из маршрутизаторов, которые извлекают из них пакеты. Они решают, в какую сеть отправлять пакеты, упаковывают их в новые ячейки и отправляют их. Если сеть между обоими маршрутизаторами использует MAC-адреса, исходный и целевой адреса этих маршрутизаторов включены в ячейку. Невозможно установить связь между двумя компьютерами в разных сетях, используя только MAC-адреса, даже если они не дублируются.

Что такое SSH?

SSH – это протокол, который работает на прикладном уровне. Это наследник telnet, который используется для удаленного подключения к VPS в текстовом режиме. Но в отличие от telnet, SSH шифруется. Он использует порт 22 TCP, но вы можете легко изменить порт в конфигурации вашего сервера. SSH позволяет пользователю аутентифицироваться несколькими различными способами:

• С помощью имени пользователя пароля;
• С помощью пары ключей – открытого и закрытого; программа, которую вы используете для подключения к SSH, должна решить математическую задачу с помощью закрытого ключа и отправить решение серверу. Каждый раз решается новая задача, поэтому ключ трудно взломать.

Наиболее популярной версией SSH-сервера является OpenSSH. Наиболее популярными клиентами являются PuTTY (для Windows) и OpenSSH (для Linux). И PuTTY и OpenSHH позволяют пользователям создавать туннели.

SSH позволяет пользователям создавать туннель TCP между сервером и клиентом и отправлять данные через этот туннель. SSH поддерживает только TCP-туннели, но вы можете обойти это, например, через прокси-сервер SOCKS. Подобный туннель устанавливается между выбранным TCP-портом на сервере и локальным портом. Конечно, он незашифрованный, так что любой пользователь может проверить, для чего он используется.

Основные понятия

Loopback интерфейс (или интерфейс обратной петли) – это виртуальная сетевая карта, установленная в системе, с IP-адресом 127.0.0.1. Доступ к этому адресу имеют только приложения, установленные в системе. Удаленный доступ к этому интерфейсу невозможен. Вы можете запустить на этом интерфейсе VPS и получить к нему удаленный доступ только из той же системы или через туннель.

SMTP – это протокол прикладного уровня, который позволяет отправлять электронные письма. Он используется как для связи между почтовыми серверами, так и между сервером и почтовым клиентом. SMTP использует порт 25 TCP для незашифрованной связи и порт 587 TCP или 465 TCP (устарел – использовать не рекомендуется) для зашифрованного соединения (SSL).

POP3 – протокол прикладного уровня, используемый для загрузки новых сообщений электронной почты с сервера на локальный почтовый клиент. Он редко используется в наши дни, поскольку он был заменен IMAP. Для незашифрованных соединений он использует порт 110 TCP, для зашифрованных – 995 TCP.

IMAP – протокол, похожий на POP3, но с поддержкой папок, ярлыков, чтения и управления сообщениями и папками на сервере без необходимости загружать все на локальный ПК и удалять с сервера. IMAP использует TCP порт 143 для незашифрованных соединений и порт 993 TCP для зашифрованных соединений.

Пример 1: Туннель к серверу IMAP

Попробуйте создать туннель между локальным портом 143 на интерфейсе loopback (127.0.0.1) и IMAP-сервером для приема почты (незашифрованное соединение) на одном удаленном компьютере.

Unix и OpenSSH

ssh abc@def -L 110:127.0.0.1:110

• abc – имя пользователя на сервере
• def – адрес сервера
• 110: – локальный порт, который будет открыт по интерфейсу loopback (127.0.0.1) на локальной машине
• 127.0.0.1 – IP-адрес компьютера, с которым создается туннель
• :110 – номер порта целевой машины, к которому подключится туннель

Windows и PuTTY

В этом разделе вы узнаете, как создать соединение с вашим VPS с помощью PuTTY. Это соединение требуется для создания туннеля.

• Выберите соединение, загрузите данные и перейдите в Connection-> SSH-> Tunnels и укажите:

Source port: 110
Destination: 127.0.0.1:110

• Поставьте галочки в Local и Auto.
• Нажмите Add. В Forwarded ports появится L110 127.0.0.1:110.
• Сохраните сессию и подключитесь с ее помощью.

Теперь вы можете просто настроить почтовый клиент для непосредственного подключения к VPS, используя порт 110 интерфейса loopback – 127.0.0.1. Вы можете сделать то же самое с разными протоколами – SMTP (25), IMAP (143) и т. д.

Пример 2: Туннель к веб-серверу

Туннель между локальным портом 8080 на локальном интерфейсе (127.0.0.1) и WWW-сервером привязан к порту 80 удаленной машины. На этот раз мы подключимся к нему, используя интерфейс loopback.

Для загрузки сайтов в браузере используется протокол HTTP.

Unix и OpenSSH

ssh abc@def -L 8080:11.22.33.44:80

• abc – имя пользователя на сервере
• def – адрес сервера
• 8080: – порт на локальной машине, который будет открыт в интерфейсе loopback (127.0.0.1)
• 22.33.44 – IP-адрес сервера, с которым создается SSH-туннель

Windows и PuTTY

• Выберите соединение и загрузите параметры.
• Выберите Connection->SSH->Tunnels.
• Установите Forwarded ports: L8080 22.33.44:80. Поставьте галочки в Local и Auto.
• Кликните Add.
• Сохраните сессию и используйте ее для подключения.

Теоретически, перейдя к 127.0.0.1:8080 в браузере, вы должны увидеть веб-сайт, расположенный на удаленном сервере, к которому мы подключились.

Практически, HTTP 1.1 представил параметр Host для запросов. Этот параметр используется для отправки домена DNS VPS, к которому вы подключаетесь. Если он использует механизм Virtual Host, вы получите либо страницу ошибки, либо главную страницу сервера, но не через туннель.

В этом случае нужно сделать еще одно: в файле hosts на локальном ПК добавьте адрес VPS и интерфейс loopback:

Где website – это адрес сайта, к которому вы хотите подключиться (без http:// в начале и / в конце).

Файл Hosts находится в каталоге /etc/hosts (Linux) или C:\Windows\system32\drivers\etc\hosts (Windows). Чтобы отредактировать этот файл, вы должны быть администратором или иметь административные привилегии.

Важно! Если вы хотите создать туннель в Unix-системах по локальному порту с номером ниже 1024, вы должны иметь права root.

Пример 3: Прокси-сервер SOCKS

Прокси-сервер SOCKS позволяет отправлять трафик с любого протокола через туннель. Со стороны он выглядит как одно TCP-соединение.

В этом примере попробуйте создать туннель между сервером SSH и клиентом по порту 5555 на интерфейсе loopback. Затем нужно настроить браузер для поддержки SOCKS в качестве прокси-сервера для каждого исходящего соединения.

Это средство может быть полезно для предотвращения ограничений в корпоративных сетях. Если порт, который использует SSH, заблокирован, можно настроить сервер для прослушивания порта 443 с помощью параметра Listen в конфигурационном файле OpenSSH (/etc/ssh/sshd_config or /etc/openssh/sshd_config).

Unix and OpenSSH

ssh abc@def -D 5555

• abc – имя пользователя
• def – адрес сервера
• 5555 – номер локального порта, на котором создается туннель

Windows and PuTTY

• Выберите соединение и загрузите настройки.
• Выберите Connection-> SSH-> Tunnels.
• Установите в Forwarded ports D5555, поставьте галочки в Dynamic и Auto.
• Нажмите Add.
• Сохраните сессию и подключитесь с ее помощью.

В настройках браузера укажите прокси-сервер SOCKS, который будет работать на 127.0.0.1:5555, пока вы не закроете соединение в PuTTY или OpenSSH.

4: Обход NAT

NAT – это механизм, который позволяет многим людям использовать одно подключение к Интернету. Маршрутизатор, использующий NAT, имеет один публичный адрес и заменяет все частные адреса в пакетах, полученных из внутренней сети, своим собственным публичным адресом и отправляет их в Интернет. При возврате пакетов он выполняет обратное действие – он запоминает IP-адреса и номера портов в специальной таблице NAT.

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

Из соображений безопасности удаленный порт 8080 будет открыт только на интерфейсе loopback VPS. Чтобы открывать соединения на каждом порту, нужно перенастроить сервер.

Откройте в текстовом редакторе файл /etc/ssh/sshd_config (или /etc/openssh/sshd_config) как root.

Раскомментируйте ее и измените значение:

Сохраните файл и закройте редактор.

# Debian/Ubuntu:
service ssh restart
# CentOS:
/etc/init.d/sshd restart

Теперь можно создать туннель.

Unix и OpenSSH

ssh abc@def -R 8080:127.0.0.1:80

• abc – имя пользователя
• def – адрес сервера
• 8080 – номер порта, который нужно открыть на удаленном сервере (прокси-сервере)
• 0.0.1 – IP-адрес, для которого создается туннель.
• 80 – номер порта, на котором откроется туннель.

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

Записки IT специалиста

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Очень часто, когда речь заходит об удаленном доступе к сетям с низким уровнем безопасности, первое что приходит на ум — это VPN, однако ради административных соединений поднимать VPN не всегда целесообразно, особенно если речь идет об аутсорсинге или «приходящем админе». Кроме того, не всегда условия связи позволяют поднять устойчивое VPN-соединение, особенно если приходится использовать мобильные сети.

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

Строго говоря, SSH-туннели не являются полноценными туннелями и это название следует рассматривать как сложившееся в профессиональной среде устойчивое наименование. Официальное название технологии — SSH Port Forwarding — это опциональная возможность протокола SSH, которая позволяет передать TCP-пакет с одной стороны SSH-соединения на другую и произвести в процессе передачи трансляцию IP-заголовка по заранее определенному правилу.

Также, в отличие от VPN-туннелей, которые позволяют передавать любой трафик в любом направлении, SSH-туннель имеет точку входа и может работать только с TCP-пакетами. По факту это больше всего похоже на проброс портов (о чем и говорит официальное название), только поверх протокола SSH.

Рассмотрим работу SSH-туннеля более подробно. В качестве примера возьмем классический случай обеспечения доступа к некоторому удаленному серверу по протоколу RDP.

Допустим, что в удаленной сети существует целевой сервер с адресом 192.168.0.105, но доступа к нему из внешней сети нет, единственное устройство к которому мы можем подключиться — это маршрутизатор с адресом 192.168.0.1 с которым мы можем установить SSH-соединение.

Остановимся на очень важном моменте: все параметры SSH-туннеля устанавливает инициатор подключения, он же SSH-клиент, вторым концом туннеля всегда является сервер, к которому мы подключаемся, он же SSH-сервер. В данном контексте следует понимать клиент и сервер сугубо как стороны соединения, например, в роли SSH-клиента может выступать VPS-сервер, а в роли SSH-сервера ноутбук админа.

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

Рассмотрим схему выше. Мы установили SSH-туннель с локальной машины к удаленному маршрутизатору, указав локальную точку входа 127.0.0.1:3389 и правило трансляции 192.168.0.105:3389. Еще раз обращаем ваше внимание, что правило трансляции не указывает на точку выхода, а определяет узел, которому будут посланы пакеты по выходу из туннеля. Если вы укажете недействительный адрес, либо узел не будет принимать соединения, то SSH-туннель установится, но доступа к целевому узлу не будет.

Согласно указанной точке входа служба SSH создаст локальный TCP-сокет, который будет ожидать подключений на порт 3389. Поэтому в окне RDP-подключения указываем в качестве назначения localhost или 127.0.0.1, RDP-клиент открывает динамический порт и отсылает пакет с адресом назначения 127.0.0.1:3389 и адресом источника 127.0.0.1:61256, о реальном назначении получателя пакета ему ничего не известно.

С точки входа данный пакет будет отправлен на другую сторону SSH-туннеля, а адрес назначения согласно правила трансляции будет изменен на 192.168.0.105:3389, и SSH-сервер примет дальнейшее решение согласно собственной таблицы маршрутизации, заменив адрес источника на свой собственный, в противном случае целевой сервер попытается отправить ответный пакет на локальный адрес.

Таким образом RDP-клиент работает с локальным сокетом и далее этого узла RDP-пакеты не уходят, внутри туннеля они передаются поверх протокола SSH в зашифрованном виде, а вот между SSH-сервером и RDP-сервером в сети 192.168.0.0 устанавливается обычное RDP-соединение, в открытом виде. Это следует учитывать при использовании небезопасных протоколов, твердо запомнив, что если правило трансляции указывает за пределы узла с точкой выхода, то такое соединение (между точкой выхода и узлом назначения) не защищается посредством SSH.

Разобравшись в общих чертах как работают SSH-туннели перейдем к практическим вариантам их использования, в качестве платформы мы будем рассматривать Linux-системы семейства Debian/Ubuntu, но все нижеизложенное с небольшими поправками будет справедливо для любой UNIX-подобной системы.

SSH-туннель с локальной точкой входа

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

Мы будем рассматривать все тот-же вариант, RDP-подключение к удаленному серверу, оранжевым пунктиром на схеме обозначено безопасное SSH-соединение, синими стрелками — обычное TCP-подключение.

В самом простом варианте мы просто устанавливаем соединение с клиентского ПК к маршрутизатору в удаленной сети, указывая в правиле трансляции целевой узел:

Ключ -L указывает на то, что точка входа расположена локально, затем через двоеточие указываются адрес и порт точки входа и адрес, порт правила трансляции. Точкой выхода является узел, к которому мы подключаемся, т.е. rt.example.com.

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

В таком случае служба SSH должна будет открыть TCP-сокет на интерфейсе 192.168.31.100, но на практике этого не произойдет. Это связано с особенностями реализации OpenSSH, который является стандартом для подавляющего большинства UNIX-подобных систем.

По умолчанию OpenSSH открывает точку входа только на локальном интерфейсе. В этом несложно убедиться:

Для того, чтобы предоставить доступ к TCP-сокету с внешних интерфейсов следует использовать ключ -g, либо добавить в конфигурационный файл /etc/ssh/sshd_config опцию:

Однако после этого сокет будет принимать соединения с любого сетевого интерфейса инициатора:

Это значит, что порт 3389 будет открыт на всех сетевых интерфейсах, поэтому если точка входа является пограничным устройством, то следует ограничить доступ к сокету, например, средствами iptables. Для примера заблокируем доступ из внешней сети (интерфейс eth0):

Таким образом рабочий туннель следует поднимать командой:

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

Также мы советуем использовать по возможности ключ -g, а не добавление опции в конфигурационный файл, так как в последнем случае вы рискуете, забыв об этой настройке, открыть наружу доступ к незащищенным службам удаленной сети.

SSH-туннель с удаленной точкой входа

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

В первом варианте удаленный сервер сам устанавливает подключение с маршрутизатором локальной сети. Это можно сделать простой командой:

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

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

на стороне SSH-сервера.

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

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

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

Снова обратим ваше внимание, что точка входа у нас располагается на противоположной стороне туннеля, поэтому трансляция указывается для стороны инициатора туннеля, т.е. в данном случае SSH-клиент устанавливает два соединения: одно SSH с rt.example.com, а второе RDP c 192.168.0.105, тогда как при туннеле с локальной точкой входа инициатор устанавливает единственное соединение с SSH-сервером.

Двойной SSH-туннель

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

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

Туннель с локальной точкой входа на ПК админа:

И туннель с удаленной точкой входа на RDP-сервере:

Мы специально указали на удаленном сервере нестандартный порт для большей наглядности и теперь давайте посмотрим, как все это работает. Начнем с RDP-сервера, он поднимает туннель с удаленной точкой входа, открывая на промежуточном сервере TCP-сокет, который будет принимать подключения на порт 3390, в качестве трансляции укажем сам RDP-сервер — 127.0.0.1:3389, т.е. все пришедшие на вход этого туннеля пакеты будут направлены на локальный порт 3389.

Туннель с локальной точкой входа на ПК админа открывает локальный сокет на порт 3389, куда будет подключаться RDP-клиент, в качестве трансляции мы указываем точку входа второго туннеля — 127.0.0.1:3390.

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

Динамический SSH-туннель

В отличие от рассмотренных выше динамический туннель работает иначе, он открывает на хосте локальный TCP-сокет, который можно использовать как SOCKS4/SOCKS5 прокси для выхода в интернет через удаленный SSH-сервер. Это может быть полезно для обхода некоторых ограничений, когда поднимать полноценный VPN в другой юрисдикции нет необходимости, а использовать публичные прокси или VPN нельзя по соображениям безопасности.

Такой вид туннеля особенно удобен, если требуется разовый выход в интернет с другого узла. Простой пример: мой хороший знакомый привез из Штатов два операторских контрактных iPhone и попросил их разблокировать. Сложностей данная операция не таит, если условия контракта не были нарушены, то достаточно зайти на сайт оператора и заполнить заявку на разблокировку. Но проблема оказалась в том, что у оператора T-Mobile доступ к данному разделу сайта был доступен только для жителей США, а соединения с публичных прокси и VPN отвергались как небезопасные.

Динамический SSH-туннель позволил быстро решить эту проблему используя VPS в Штатах. Чтобы создать такой туннель введите команду:

Где 1080 — порт на котором будет доступен наш SOCKS-прокси. Остается только настроить браузер на использование локального прокси-сервера.

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

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

Несколько слов о безопасности

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

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

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

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

SSH-туннели в Windows

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

Откроем PuTTY и в левой части дерева перейдем в Connection — SSH -Tunnels:

Перед нами откроется следующее окно, основные настройки туннеля сосредоточены внизу, и мы выделили их красной рамкой. Source port — предназначен для указания порта точки входа, которая всегда располагается на локальном интерфейсе (127.0.0.1). Destination — трансляция, т.е. куда будут отправлены пакеты с точки выхода. Радиопереключатели Local — Remote — Dynamic задают тип туннеля и аналогичны ключам -L, -R и -D.

После того, как вы заполнили все необходимые поля можно добавить туннель кнопкой Add. Чтобы разрешить внешним узлам доступ к локальному сокету точки входа установите галочку Local ports accept connections from other hosts. В данном случае следует также ограничить доступ к открытым портам средствами брандмауэра Windows или стороннего сетевого фильтра.

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

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал: