Настроить туннель до сервера

Прямой VPN-туннель между двумя компьютерами находящимися за NAT провайдеров с использованием UDP hole punching

Введение

Теория

Я давно задумался о решении по организации канала передачи данных непосредственно от узла к узлу, которые находятся за NATом провайдеров, без использования серверов-посредников. Перебрав некоторое количество статей о различных технологиях типа GRE-туннелей, IPsec, UDP Hole Punching, OpenVPN и прочего, я понял, что узлы должны пробивать соединение навстречу друг другу, то есть посылать пакеты на IP и порт удаленного узла. Поставил несколько опытов по организации GRE-туннеля через NAT, передачу сообщения при помощи NetCat навстречу друг другу, иногда это работало, иногда нет, всё зависело от типа используемого провайдером NAT. Не так давно попалась на глаза интересная статья, в которой было описание организации работы OpenVPN соединения между двумя компьютерами (далее узлами). Я прочитал, проверил и заработало, но при условии, что локальный порт узла и внешний порт будут совпадать, то есть мой провайдер будет использовать Cone NAT. Мне же стало интересно организовать туннель между двумя компьютерами при условии, что оба будут находятся за любым типом (Cone или Symmetric) NAT, то есть локальный порт может не совпадать с внешним портом. Задача уперлась в невозможность определения текущего порта внешнего интерфейса без внешней помощи. Если внешний IP-адрес хоть как-то можно узнать (например: curl ifconfig.me), а вот с определением текущего внешнего порта возникла трудность.

Практика

Для решения этой задачи пришлось использовать VPS (S-синий овал), на нем я поднял скрипт который выполнял роль «Соединителя», что-то типа STUN-сервера: при помощи утилиты TCPDump получал UDP-пакет (далее везде используется UDP протокол) на определенный интерфейс и порт, парсил содержимое пакета, определял IP-адрес/порт источника и отвечал утилитой NetCat возвращая текущие параметры (IP-адрес и порт) соединения, а так же параметры (IP-адрес и порт) удаленного узла к которому нужно подключиться, если эти данные были доступны, иначе ждал пока они не появятся. Все это дело сопоставлялось с идентификатором (ID) соединения, так как несколько соединений могли мешать друг другу, при использовании ID все решалось. Также была проблема того, что узел получал свои же старые данные и пытался по ним подключиться и это решилось с помощью хеша Hostname.

На узлах A и B я использовал скрипт и сгенерированный заранее ключ для авторизации VPN-соединения, работало это так: запускался скрипт, случайно выбирался локальный порт в диапазоне от 20000 до 65000 и с этого порта отправлялся пакет на VPS, который содержал в себе ID соединения и хеш hostname, с помощью утилиты NetCat и тут же запускался TCPDump ожидая ответа. В ответ приходил пакет который содержал в себе текущие данные (IP-адрес/порт) этого узла, а при наличие данных удаленного узла, они тоже приходили и начинался обмен приветствиями между узлами. Если же данных удаленного узла не было, то опрос повторялся с периодичностью 30-45 секунд, для поддержания сессии. В момент когда все необходимые данные (IP-адрес и порт текущего узла и удаленного) были на узлах, начинался обмен пакетами, пакет содержал в себе число m=0 и сгенерированное число от 0 до 254 (это число использовалось для генерации внутреннего IP-адреса VPN-соединения). Удаленный узел получив пакет с m=0 отправлял в ответ m=1 и так далее до 10. При получении пакета m=10 инициировалась посылка пачки пакетов с периодичность в 1 секунду с m=13 и запуск OpenVPN, удаленный узел получив m=13 тоже запускал OpenVPN используя локальный порт, IP-адрес и порт удаленного узла, а также сгенерированный внутренний IP вида 10.X.X.<1,2>/30.

Схема прямого VPN-туннеля и передачи данных между узлами, без участия сервера
Внимание: скрипты написаны и проверены на ОС Ubuntu 18.04 и Debian 9

Запускается автоматически строкой в /etc/rc.local

где 13013 — это порт который нужно слушать, /var/log/connector2.log — лог.

Скрипт на узлах: # cat vpn7.sh

Скопировать скрипт в буфер и вставить в тектовый редактор, например:

Сделать скрипт исполняемым:

Для первого запуска сгенерируем ключ авторизации secret.key, на удаленной стороне генерировать не надо, нужно скопировать его:

Запустим скрипт, например так:

Ключ 517vA0051smB4dE сгенерировал на strongpasswordgenerator.com

Запускается автоматически строкой в /etc/rc.local

где ID-соединения — это любая уникальная фраза для вашего соединения, /var/log/vpn7.log — лог соединения, ipsrv=«45.141.103.45» — IP-адрес узла где запущен connector2.sh (первый скрипт).

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

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

Приемущества:

• простота в настройке и использовании
• трафик идет напрямую
• трафик шифруется и защищен от перехвата
• нет необходимости пробрасывать порты
• скрипт запускается автоматически

Недостатки:

• главный недостаток это использования VPS как источника данных для соединения, но я думаю над этим
• некоторые провайдеры блокируют трафик между другими провайдерами (замечено у сотовых операторов)
• при использовании с обоих сторон одного провадера может не сработать, зависит от типа NAT
• при использовании провадером «жесткого» NAT может не сработать

В планах дальнейшее развитие скрипта до какой-нибудь системы, минимизировать время ожидания ответов, прикрутить шифрование передаваемых данных, адаптировать его к ОС Windows и Android, научить работать через Proxy и тому подобное.

Думаю на фоне дефицита белых IPv4 адресов моё решение будет актуально, ровно до тех пор, пока в каждый дом не придет IPv6.

Обновлено 11.12.2019, добавлено:

• команда активации защиты от подмены адресов, уязвимость CVE-2019-14899
• команды завершающие зависшие процессы NC, ускоряется процесс установки соединения
• внутренние IP-адреса генерируются при первом запуске и их составляющие хранятся в vpn.cfg

Другая моя реализация VPN-туннеля, без использования VPS, с использованием STUN и Яндекс.Диска опубликована тут

Источник

Поднимаем VPN-туннель из мира домой в обход NAT

.

Хочу рассказать вам про то как имея в интернете свой VPS-сервер можно поднять туннель в домашнюю сеть. И не платить при этом за статический IP провайдеру, и даже находясь за NAT, все равно сделать доступными в интернете свои домашние сервисы.

Исходные данные

• VPS сервер на debian со статическим реальным IP
• роутер с прошивкой OpenWRT, который находится за провайдерским NAT
• домашняя сеть с компьютерами и виртуальными машинами в 192.168.1.0/24

Настройка туннеля

Первым делом установим и настроим OpenVPN сервер на нашем VPS:

Отредактируем файл конфигурации:

Здесь 10.9.8.x будет наша VPN-сеть, в которой адрес 10.9.8.1 мы назначем VPN-серверу, а адрес 10.9.8.2 VPN-клиенту.
Последняя строчка являет ссобой статисческий маршрут, который нужен для того, что бы наш VPS знал что путь в нашу домашнюю сеть лежит через роутер

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

И можно запускать демона:

Теперь установим OpenVPN на наш роутер с которого мы будем инициализировать VPN-соединение:

Скопируем ключ на наш рутер, исполюзуя scp:

Отредактируем конфигурацию интерфейса:

keepalive 60 180
Означает следующее: каждые 60 секунд посылать ping на удаленный хост, и, если за 180 секунд не было получено ни одного пакета — то перезапускать туннель.

И проверим, все ли у нас заработает:

Если все ок, то запустим и добавим OpenVPN демона в автозапуск:

Маршрутизация

Теперь настроим маршрутизацию.

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

Создадим файлик и запишем в него эти правила:

Cделаем его исполняемым:

И добавим его в /etc/rc.local для автозапуска:

Добавлять нужно перед exit 0

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

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

Где XX.XX.XX.XXX — внешний IP сервера, 192.168.1.200 — IP моей машины внутри домашней сети, 666 — порт при обращении к которому я попадаю на эту машину

PS: Если у вас что-то не получается убедитесь что на вашем VPS есть и подключены все необходимые для этого модули ядра

Источник

Практические советы, примеры и туннели SSH

Практические примеры SSH, которые выведут на новый уровень ваши навыки удалённого системного администратора. Команды и советы помогут не только использовать SSH , но и более грамотно перемещаться по сети.

Знание нескольких трюков ssh полезно любому системному администратору, сетевому инженеру или специалисту по безопасности.

Практические примеры SSH

Сначала основы

Разбор командной строки SSH

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

• -v : вывод отладочной информации особенно полезен при анализе проблем аутентификации. Можно использовать несколько раз для вывода дополнительной информации.
• — p 22 : порт для подключения к удалённому серверу SSH. 22 не обязательно указывать, потому что это значение по умолчанию, но если протокол на каком-то другом порту, то указываем его с помощью параметра -p . Порт прослушивания указывается в файле sshd_config в формате Port 2222 .
• -C : сжатие для соединения. Если у вас медленный канал или вы просматриваете много текста, это может ускорить связь.
• neo@ : строка перед символом @ обозначает имя пользователя для аутентификации на удалённом сервере. Если не указать его, то по умолчанию будет использоваться имя пользователя учётной записи, в которую вы вошли в данный момент (

$ whoami). Пользователя также можно указать параметром -l .

remoteserver : имя хоста, к которому подключается ssh , это может быть полное доменное имя, IP-адрес или любой хост в локальном файле hosts. Для подключения к хосту, который поддерживает и IPv4, и IPv6, можно добавить в командную строку параметр -4 или -6 для правильного резолвинга.

Все вышеперечисленные параметры являются необязательными, кроме remoteserver .

Использование файла конфигурации

/.ssh/config , но его можно определить как параметр для опции -F .

В приведённом выше примерном файле конфигурации ssh две записи хоста. Первая обозначает все хосты, для всех применяется параметр конфигурации Port 2222. Вторая говорит, что для хоста remoteserver следует использовать другое имя пользователя, порт, FQDN и IdentityFile.

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

Копирование файлов по SSH с помощью SCP

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

В этом примере файл mypic.png скопирован на remoteserver в папку /media/data и переименован в mypic_2.png.

Не забывайте о разнице в параметре порта. На этом попадаются многие, кто запускает scp из командной строки. Здесь параметр порта -P , а не -p , как в ssh-клиенте! Вы забудете, но не волнуйтесь, все забывают.

Для тех, кто знаком с консольным ftp , многие из команд похожи в sftp . Вы можете сделать push, put и ls, как сердце пожелает.

Практические примеры

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

1. SSH socks-прокси

Функция SSH Proxy под номером 1 по уважительной причине. Она более мощная, чем многие предполагают, и даёт вам доступ к любой системе, к которой имеет доступ удалённый сервер, используя практически любое приложение. Клиент ssh может туннелировать трафик через прокси-сервер SOCKS одной простой командой. Важно понимать, что трафик к удалённым системам будет исходить от удалённого сервера, так будет указано в логах веб-сервера.

Здесь мы запускаем socks-прокси на TCP-порту 8888, вторая команда проверяет, что порт активен в режиме прослушивания. 127.0.0.1 указывает, что служба работает только на localhost. Мы можем применить немного другую команду для прослушивания всех интерфейсов, включая ethernet или wifi, это позволит другим приложениям (браузерам и т д.) в нашей сети подключаться к прокси-сервису через ssh socks-прокси.

Теперь можем настроить браузер для подключения к socks-прокси. В Firefox выберите Настройки | Основные | Параметры сети. Укажите IP-адрес и порт для подключения.

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

Активация socks-прокси в Chrome

Запуск Chrome с определёнными параметрами командной строки активирует socks-прокси, а также туннелирование DNS-запросов из браузера. Доверяй, но проверяй. Используйте tcpdump для проверки, что DNS-запросы больше не видны.

Использование других приложений с прокси

Имейте в виду, что многие другие приложения тоже могут использовать socks-прокси. Веб-браузер просто самое популярное из них. У некоторых приложений есть параметры конфигурации для активации прокси-сервера. Другим нужно немного помочь вспомогательной программой. Например, proxychains позволяет запустить через socks-прокси Microsoft RDP и др.

Параметры конфигурации socks-прокси задаются в файле конфигурации proxychains.

Подсказка: если используете удалённый рабочий стол из Linux на Windows? Попробуйте клиент FreeRDP. Это более современная реализация, чем rdesktop , с гораздо более плавным взаимодействием.

Вариант использования SSH через socks-прокси

Вы сидите в кафе или гостинице — и вынуждены использовать довольно ненадёжный WiFi. С ноутбука локально запускаем ssh-прокси и устанавливаем ssh-туннель в домашнюю сеть на локальный Rasberry Pi. Используя браузер или другие приложения, настроенные для socks-прокси, мы можем получить доступ к любым сетевым службам в нашей домашней сети или выйти в интернет через домашнее подключение. Всё между вашим ноутбуком и домашним сервером (через Wi-Fi и интернет до дома) зашифровано в туннеле SSH.

2. Туннель SSH (переадресация портов)

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

Разберём параметр -L . Его можно представить как локальную сторону прослушивания. Таким образом, в примере выше порт 9999 прослушивается на стороне localhost и переадресуется через порт 80 на remoteserver. Обратите внимание, что 127.0.0.1 относится к localhost на удалённом сервере!

Поднимемся на ступеньку. В следующем примере порты прослушивания связываются с другими узлами локальной сети.

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

3. SSH-туннель на сторонний хост

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

В данном примере мы перенаправляем туннель от remoteserver к веб-серверу, работающему на 10.10.10.10. Трафик с remoteserver к 10.10.10.10 уже не в SSH-туннеле. Веб-сервер на 10.10.10.10 будет считать remoteserver источником веб-запросов.

4. Обратный SSH-туннель

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

В этой SSH-сессии устанавливается соединение с порта 1999 на remoteserver к порту 902 на нашем локальном клиенте.

5. Обратный прокси SSH

В этом случае мы устанавливаем socks-прокси на нашем ssh-соединении, однако прокси слушает на удалённом конце сервера. Подключения к этому удалённому прокси теперь появляются из туннеля как трафик с нашего localhost.

Устранение проблем с удалёнными SSH-туннелями

Если у вас возникли проблемы с работой удалённых опций SSH, проверьте с помощью netstat , к каким ещё интерфейсам подключён порт прослушивания. Хотя мы в примерах указали 0.0.0.0, но если значение GatewayPorts в sshd_config установлено в значение no, то листенер будет привязан только к localhost (127.0.0.1).

Предупреждение безопасности

Обратите внимание, что при открытии туннелей и socks-прокси внутренние сетевые ресурсы могут быть доступны ненадёжным сетям (например, интернету!). Это может быть серьёзной угрозой безопасности, поэтому убедитесь, что вы понимаете, что представляет собой слушатель и к чему у него есть доступ.

6. Установка VPN по SSH

Общий термин среди спецов по методам атаки (пентестеры и проч.) — это «точка опоры в сети». После установления соединения в одной системе эта система становится шлюзом для дальнейшего доступа к сети. Точка опоры, которая позволяет двигаться вширь.

Для такой точки опоры мы можем использовать SSH-прокси и proxychains, однако есть некоторые ограничения. Например, не получится работать напрямую с сокетами, поэтому мы не сможем сканировать порты внутри сети через Nmap SYN .

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

Метод использует ssh , iptables , tun interfaces и маршрутизацию.

Сначала нужно задать эти параметры в sshd_config . Поскольку мы вносим изменения в интерфейсы и удалённой, и клиентской системы, нам нужны права root с обеих сторон.

Затем установим ssh-соединение, используя параметр, который запрашивает инициализацию tun-устройств.

Теперь у нас должно быть устройство tun при показе интерфейсов ( # ip a ). Следующий шаг добавит IP-адреса к туннельным интерфейсам.

Сторона клиента SSH:

Сторона сервера SSH:

Теперь у нас прямой маршрут к другому хосту ( route -n и ping 10.10.10.10 ).

Можно маршрутизировать любую подсеть через хост на другой стороне.

На удалённой стороне необходимо включить ip_forward и iptables .

Бум! VPN через туннель SSH на сетевом уровне 3. Вот это уже победа.

Если возникают какие-то проблемы, используйте tcpdump и ping , чтобы установить причину. Поскольку мы играем на уровне 3, то наши пакеты icmp пойдут через этот туннель.

7. Копирование ключа SSH (ssh-copy-id)

/.ssh/id_rsa.pub (или ключ по умолчанию) с вашей системы в

/.ssh/authorized_keys на удалённом сервере.

8. Удалённое выполнение команд (неинтерактивно)

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

В данном примере grep выполняется на локальной системе после того, как лог скачался по ssh-каналу. Если файл большой, удобнее запустить grep на удалённой стороне, просто заключив обе команды в двойные кавычки.

Другой пример выполняет ту же самую функцию, что и ssh-copy-id из примера 7.

9. Удалённый перехват пакетов и просмотр в Wireshark

Я взял один из наших примеров по tcpdump. Используйте его для удалённого перехвата пакетов с выдачей результата непосредственно в GUI локального Wireshark.

10. Копирование локальной папки на удалённый сервер по SSH

Красивый трюк, который сжимает папку с помощью bzip2 (это параметр -j в команде tar ), а затем извлекает поток bzip2 на другой стороне, создавая на удалённом сервере дубликат папки.

11. Удалённые приложения GUI с переадресацией SSH X11

Если на клиенте и удалённом сервере установлены «иксы», то можно удалённо выполнить команду GUI, с окном на вашем локальном рабочем столе. Эта функция существует давным давно, но по-прежнему очень полезна. Запустите удалённый веб-браузер или даже консоль VMWawre Workstation, как я делаю в этом примере.

Требуется строка X11Forwarding yes в файле sshd_config .

12. Удалённое копирование файлов с помощью rsync и SSH

rsync во многом удобнее scp , если требуется периодическое резервное копирование каталога, большого количества файлов или очень больших файлов. Здесь есть функция восстановления после сбоя передачи и копирования только изменённых файлов, что сохраняет трафик и время.

В этом примере используется сжатие gzip (-z) и режим архивирования (-a), который включает рекурсивное копирование.

13. SSH через сеть Tor

Анонимная сеть Tor может туннелировать SSH-трафик с помощью команды torsocks . Следующая команда прокинет ssh-прокси через Tor.

Torsocks будет использовать для прокси порт 9050 на localhost. Как всегда при использовании Tor необходимо серьёзно проверять, какой трафик туннелируется и другие проблемы операционной безопасности (opsec). Куда идут ваши DNS-запросы?

14. SSH к инстансу EC2

Параметр -i просто указывает ssh-клиенту использовать этот ключ. Файл

/.ssh/config идеально подходит для автоматической настройки использования ключа при подключении к хосту ec2.

15. Редактирование текстовых файлов с помощью VIM через ssh/scp

Для всех любителей vim этот совет сэкономит немного времени. С помощью vim файлы редактируются по scp одной командой. Этот метод просто создаёт файл локально в /tmp , а затем копирует его обратно, как только мы его сохранили из vim .

Примечание: формат немного отличается от обычного scp . После хоста у нас двойной // . Это ссылка на абсолютный путь. Один слэш будет означать путь относительно домашней папки users .

Если увидите такую ошибку, дважды проверьте формат команды. Обычно это означает синтаксическую ошибку.

16. Монтирование удалённого SSH как локальной папки с SSHFS

При помощи sshfs — клиента файловой системы ssh — мы можем подключить локальный каталог к удалённому местоположению со всеми взаимодействиями файлов в зашифрованном сеансе ssh .

На Ubuntu и Debian установим пакет sshfs , а затем просто приимонтируем удалённое расположение к нашей системе.

17. Мультиплексирование SSH с помощью ControlPath

По умолчанию при наличии существующего подключения к удалённому серверу с помощью ssh второе подключение с помощью ssh или scp устанавливает новый сеанс с дополнительной аутентификацией. Опция ControlPath позволяет использовать существующий сеанс для всех последующих соединений. Это значительно ускорит процесс: эффект заметен даже в локальной сети, а тем более при подключении к удалённым ресурсам.

ControlPath указывает сокет для проверки новыми соединениями на предмет наличия активной сессии ssh . Последняя опция означает, что даже после выхода из консоли существующий сеанс останется открытым 10 минут, так что в течение этого времени вы сможете повторно подключиться по существующему сокету. Для дополнительной информации смотрите справку ssh_config man .

18. Потоковое видео по SSH с помощью VLC и SFTP

Даже давние пользователи ssh и vlc (Video Lan Client) не всегда знают об этой удобной опции, когда очень нужно посмотреть видео по сети. В настройках File | Open Network Stream программы vlc можно ввести местоположение как sftp:// . Если требуется пароль, появится запрос.

19. Двухфакторная аутентификация

Такая же двухфакторная аутентификация, как у вашего банковского счёта или учётной записи Google, применима к сервису SSH.

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

20. Прыжки по хостам с ssh и -J

Если из-за сегментации сети приходится переходить через несколько хостов ssh, чтобы добраться до конечной сети назначения, вам сэкономит время ярлык -J.

Здесь главное понимать, что это не аналогично команде ssh host1 , затем user@host1:

$ ssh host2 и т. д. Параметр -J хитро использует переадресацию, чтобы localhost устанавливал сеанс со следующим хостом в цепочке. Таким образом, в приведённом выше примере наш localhost аутентифицируется на host4. То есть используются наши ключи localhost, а сеанс от localhost до host4 полностью зашифрован.

Для такой возможности в ssh_config укажите опцию конфигурации ProxyJump. Если регулярно приходится переходить через несколько хостов, то автоматизация через конфиг сэкономит массу времени.

21. Блокировка попыток брутфорса SSH с помощью iptables

Любой, кто управлял сервисом SSH и просматривал логи, знает о количестве попыток брутфорса, которые происходят каждый час каждый день. Быстрый способ уменьшить шум в логах — перенести SSH на нестандартный порт. Внесите изменения в файл sshd_config с помощью параметра конфигурации Port##.

С помощью iptables тоже можно легко блокировать попытки подключения к порту по достижении определённого порога. Простой способ сделать это — использовать OSSEC, поскольку он не только блокирует SSH, но выполняет кучу других мер по обнаружению вторжений на базе имени хоста (HIDS).

22. SSH Escape для изменения переадресации портов

И наш последний пример ssh предназначен для изменения переадресации портов на лету в рамках существующего сеанса ssh . Представьте такой сценарий. Вы глубоко в сети; возможно, прыгнули через полдюжины хостов и вам нужен локальный порт на рабочей станции, который перенаправлен на Microsoft SMB старой системы Windows 2003 (кто-нибудь помнит ms08-67?).

Нажав enter , попробуйте ввести в консоли

C . Это управляющая последовательность в сессии, позволяющая вносить изменения в существующее соединение.

Здесь вы можете увидеть, что мы переадресовали наш локальный порт 1445 на хост Windows 2003, который нашли во внутренней сети. Теперь просто запустите msfconsole , и можно идти дальше (предполагая, что вы планируете использовать этот хост).

Завершение

Эти примеры, советы и команды ssh должны дать отправную точку; дополнительная информация о каждой из команд и возможностей доступна на справочных страницах ( man ssh , man ssh_config , man sshd_config ).

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

Источник