Привет, дорогой читатель!
Я не мог пройти стороной такую тему как SSH. Не по части шифрования, не по части почему SSH, а не TELNET. Все это очевидно и скучно.
Многие инженеры* используют SSH в своей работе. Но далеко не все осведомлены в том какой это мощный и гибкий сетевой инструмент, позволяющий быстро развернуть безопасный канал связи в любой нестандартной ситуации.
*Под инженерами я подразумеваю: системных/сетевых администраторов, DevOps(Net) инженеров, специалистов по ИБ, разработчиков (в большей степени backend профиля)
В первой части (именно в этой статье) я освещу общие концепции по следующим кейсам использования SSH:
- Local TCP port forwarding (прямой SSH туннель) SSH port forwarding с jumphost;
- Local TCP port forwarding chain через несколько узлов (цепочка прямых SSH туннелей);
- Remote TCP forwarding (обратный SSH туннель);
Во второй части (выйдет на новогодних каникулах) я освещу очень крутые кейсы:
4. Dynamic TCP/UDP port forwarding с помощью SSH VPN Tunnel;
5. Временное расшаривание интернета на машине к которой есть доступ по ssh, но у которой нет доступа в интернет.
Сразу скажу, что перечень пунктов и общий стиль взят с отличной статьи nitro2005 под названием Магия SSH. Если хотите можете читать ее, она отличная и быстро введет вас в понимание общего принципа. Что же сделал я и почему стоит прочитать мой вариант?
Отвечаю на вопрос: ну во-первых текст и подача у меня своя. Из материала статьи коллеги я взял только общую канву. Во-вторых, чтобы вам было проще разобраться я потратил время и сделал динамичные gif, которые позволят вам увидеть процесс в динамике. В статичных картинках к сожалению нет такой возможности. В-третьих, по каждому пункту я описываю общую концепцию и перехожу к примеру на реальной инфраструктуре, развертывание которой описано в бесплатной первой ступени моего курса "Сети и безопасность в Linux". Тут вам предоставлена возможность почитать статью в расширенном варианте, т.е. с описанием того как настраивается та или иная концепция в реальности. Вы можете просто прочитать, что уже будет большим плюсом. Но, а если ваша задача попробовать сделать тоже самое ручками и реально приобрести практический навык, то на моей учебной платформе есть все для этого и совершенно бесплатно. Все что вам потребуется это зарегистрироваться на портале. :)
В ленте бесплатных обзорных тем и уроков вы найдете:
Урок №1 Магия SSH или как с помощью SSH делать крутые вещи. Local TCP port forwarding (прямой SSH туннель)
Урок №2 Local TCP port forwarding chain через несколько узлов (цепочка прямых SSH туннелей)
Урок №3 Remote TCP forwarding (обратный SSH туннель)
Ссылка на учебную платформу:
Итак поехали про общую концепцию в разных сценариях использования ssh!
1. Local TCP port forwarding (прямой SSH туннель) SSH port forwarding с jumphost.
-L - указывает на то, что туннель доступен на локальном интерфейсе, в нашем случае на петлевом интерфейсе lo c IP а адресом 127.0.0.1.
WEB port 8080 взят в качестве примера, проброшен может быть любой порт даже порт СУБД (Postgres, MySQL).
Зачем это все может понадобиться?
Ну во-первых скорость и простота организации доступа - вам нужна всего одна команда:
host1# ssh -L 9999:localhost:8080 host2
Во-вторых безопасность - будет задействовано шифрование. Вам не надо самому разбираться в шифровании и PKI как того требует любое VPN решение;
В-третьих маршрутизация - не всегда, я бы сказал далеко не всегда есть возможность обеспечить связность штатной маршрутизацией, особенно при инсталляциях или в связи с политиками ИБ .Это может быть долго и не целесообразно и не безопасно. Тут получается смесь всего...
Вторым вариантом Local TCP port forwarding является подключение через SSH-jump Server.
jump host aka install server aka jumpbox aka инсталляционный сервер - так называют специально отведенный хост в сети, предназначенный для доступа к устройствам в демилитаризованной зоне организации. Схема будет выглядеть так:
host1# ssh -L 9999:host3:8080 host2
До настоящего момента защищенный канал строился с хоста непосредственно заинтересованного в доступе, т.е. с петлевого интерфейса. А что, если заинтересованный хост не имеет прямого доступа по ssh, но имеет вышестоящий хост (роутер), которым управляет ваш коллега? Вы можете попросить запустить ssh туннель не на петлевом интерфейсе, а на интерфейсе который доступен по сети заинтересованному хосту, тем самым создав слушающий порт с пробросом на сеть назначения в которой находится необходимый хост и прослушиваемый им порт.
Давайте взглянем на картинку, чтобы лучше понять о чем идет речь:
0.0.0.0 - это значит, что порт 9999 будет прослушиваться на всех существующих в системе интерфейсах.
2. Local TCP port forwarding chain через несколько узлов (цепочка прямых SSH туннелей)
Вот к примеру если у вас есть цепочка hostA<-->GW1<-->GW2<-->hostB. Вы управляете hostA (клиентское ПО) и вам требуется доступ по ssh к хосту hostB или к приложению, прослушивающему порт (серверное ПО) и ожидающему подключение. GW1, GW2 это наши шлюзы в разных ЦОД - это не классические пограничные роутеры. Роутеры не в нашем управлении.
Т.е. hostA может достучаться до GW1, hostB до GW2. GW1 и GW2 доступны друг другу на L3 уровне, для них настроена классическая маршрутизация.
Стоит задача оперативно связать hostA c hostB с целью что-то протестировать. VPN и полноценная маршрутизации по различным причинам могут быть нам не доступны: долго, доп. ПО и прочее.
Что в этой ситуации вы выберете? Очевидно ssh может прийти на помощь. Как мы можем попасть на hostB по ssh разово без предварительной подготовки?
Ну очевидно вы сделаете так:
hostA# ssh GW1
GW1# ssh GW2
GW2# ssh hostB
Если предположить, что нам этого не достаточно и нужная сквозная связность hostA<--->hostB, то что нам мешает сделать три ssh туннеля и получить эту связность?
Ответ - ничего)
Для этого достаточно иметь ssh доступ ко всем звеньям цепи. Ну а с точки зрения маршрутизации нам достаточно наличия connected маршрутов между хостами и GW, и штатная L3 связность между шлюзами.
Традиционно на анимации общая концепция:
hostA# ssh -L 6661:localhost:6662 GW1
GW1# ssh -L 6662:localhost:6663 GW2
GW2# ssh -L 6663:localhost:8080 hostB
3.Remote TCP forwarding (обратный SSH туннель)
Все это время Local означало, что направление установления ssh туннеля и направление исходящего соединения от клиента к серверу совпадают.
Давайте рассмотрим другую ситуацию...
Что если нам понадобилось подключиться по ssh или прокинуть tcp порт к серверу не имеющему прямого доступа из Интернета. Обычно доступ к внутренним ресурсам извне закрыт по умолчанию, но исходящие соединения по таким портам как 80, 443, 53 разрешены. Либо ресурсы находятся за NAT и нет возможности использовать белые адреса для проброса tcp из WAN в LAN.
В первом случае такая задача часто возникает у хакеров когда имея доступ к внутренним ресурсам они создают возможность подключения к ним из вне. Таким образом производится обход NAT.
Второй случай это к примеру ваш домашний компьютер с VirtualBox и виртуальными машинами и провайдер вам не предоставляет белый IP, но вы тем не менее хотели бы иметь доступ к своему компьютеру из сети интернет.
Для первого и второго случая есть решение - реверсивный SSH туннель. С помощью такого вида туннеля можно организовывать Remote TCP forwarding. Об этом и пойдет дальнейший разговор...
В общем виде принцип выглядит так:
Я специально использовал стрелки и для ssh соединения и для сессии app client--> app server. Вот эта разнонаправленность и лежит в основе названия - реверс.
Примечание: Понятие реверсивный (реверс) вы встретите и в теме прокси. Прокси бывают обычными и реверсивными. Обычный для исходящих соединений из LAN в WAN, реверсивный для входящих из WAN в LAN. Останавливаться здесь на этом не будем, но стоит помнить об этой аналогии для общей картинки.
Рассматриваемая схема очень напоминает историю с прокси, но прокси это когда сессия разрывается либо на уровне L7 (http), либо на уровне L4(tcp). В нашем же случае сессия на уровне app одна без разрывов.
А теперь я покажу реальный кейс. У меня на ноутбуке в VirtualBox развернута виртуальная инфраструктура. Возможности привязать белый адрес нет, да и если бы была, то это бы не подошло ведь ноутбук у меня с собой и естественно провайдеры меняются в зависимости от того откуда я работаю.
На этом рассмотрение общей концепции использования ssh в нестандартных ситуациях завершено. Этого достаточно для общего понимания. Если хотите на реальных примерах, с реальными командами настройками и так же в динамике, то это на учебный портал. В самом начале я приводил все необходимые ссылки и инструкции.
Ждите на праздниках часть 2 и очень крутые примеры. С наступающими, всем вам благ, здоровья и развития!
P.S. Если материал был полезен не забывайте отблагодарить лайком или комментарием.
