Использование SSH для проброса сетевого трафика
Протокол SSH активно используется для удаленного администрирования UNIX-подобных операционных систем. Он предоставляет возможности удаленного терминального подключения по сети с возможностями получить интерактивный сеанс с командным интерпретатором на удаленной системе или просто для выполнения отдельных команд. Кроме того, протокол SSH используется как транспорт для защищенной передачи трафика сетевых приложений, таких как копирование по сети, передача по сети графической информации и т. п.
В этой статье мы рассмотрим возможности SSH по обеспечению передачи произвольного трафика внутри SSH-соединения, иными словами — туннелированию трафика. Туннелирование трафика средствами SSH позволяет обеспечить работу различных сетевых приложений даже в том случае, когда настройками межсетевого экрана на пути передачи данных ничего кроме протокола SSH не разрешено.
У протокола SSH существует несколько реализаций, будем рассматривать OpenSSH — реализацию протокола, разработанную в рамках проекта OpenBSD и наиболее популярную в настоящий момент в целом ряде операционных систем, в том числе и во всём многообразии различных Linux.
Перенаправление локального порта
Данный режим туннелирования предназначен для проброса сетевого трафика в случае, когда клиентская часть сетевого приложения работает локально, а серверная часть, то есть сама сетевая служба, расположена в удаленном сетевом сегменте за SSH-сервером.
Смысл названия этого способа туннелирования — перенаправление локального порта — в том, что трафик, идущий на локальный порт SSH-клиента, доступный с этого клиента и в рамках локального сетевого сегмента, перенаправляется на сетевой сервер host:hostport, расположенный в удаленном сетевом сегменте за SSH-сервером и недоступный напрямую.
Синтаксис использования SSH для перенаправления локального порта:
$ ssh -L port:host:hostport user@sshserver
SSH-клиент, запущенный таким образом, устанавливает SSH-соединение с сервером sshserver, выполнив аутентификацию под пользователем user, и начинает прослушивать TCP-порт, указанный в параметре port.
Предполагается, что клиент сетевого приложения будет соединяться с портом port узла, на котором работает SSH-клиент. Последний, изобразив из себя таким образом сетевую службу, весь полученный от приложения трафик будет отправлять по установленному SSH-соединению на SSH-сервер. А тот, в свою очередь, перенаправит этот трафик на узел host, TCP-порт hostport, расположенный в удаленной сети.
Такой вариант туннелирования не требует каких-либо специфических настроек на клиентской и серверной стороне сетевого приложения. Всё, что нужно (кроме запуска клиента SSH с соответствующими параметрами), — это в настройках клиентской стороны в качестве сервера указать узел, на котором работает SSH-клиент, и порт, заданный параметром port.
Перенаправление удаленного порта
Этот вариант туннелирования предназначен для противоположного размещения серверной и клиентской части сетевого приложения. Серверная часть находится в том сетевом сегменте, где запускается SSH-клиент, а клиентская, наоборот, находится в сети SSH-сервера.
Синтаксис использования клиента openssh для реализации перенаправления удаленного порта выглядит следующим образом:
$ ssh -R port:host:hostport user@sshserver
Порт port, к которому должна подключаться клиентская часть сетевого приложения, в данном случае прослушивается SSH-сервером. А полученный трафик отправляется по SSH-соединению и далее с помощью SSH-клиента доставляется на серверную часть сетевого приложения на host:hostport.
Динамическая переадресация портов (SOCKS-прокси)
Этот же вариант туннелирования похож на перенаправление локального порта с той лишь разницей, что противоположный конец сетевого взаимодействия задается не в параметрах команды SSH-клиента, а определяется в рамках взаимодействия по протоколу SOCKS клиентской части сетевого приложения и SSH-клиента. Собственно, SSH-клиент в данном случае выполняет роль SOCKS-прокси.
Синтаксис запуска клиента openssh для реализации динамической переадресации выглядит так:
$ ssh -D port user@sshserver
Использование такого режима туннелирования требует наличия поддержки работы через SOCKS-прокси клиентской части сетевого приложения (и его соответствующей настройки). В частности, из сетевых приложений, традиционно оснащенных возможностью работать через SOCKS, стоит отметить веб-браузеры и FTP-клиенты.
SSH-туннели глазами безопасника
А теперь давайте взглянем на все эти замечательные возможности глазами специалиста, который воплотил на межсетевом экране политику безопасности компании, подразумевающую вполне определенный перечень (в том числе и SSH) возможных соединений в защищаемую сеть из-за пределов периметра. Но вместе с SSH получивший ПОТЕНЦИАЛЬНО ВСЁ, ЧТО УГОДНО. Естественно, воспользоваться этими возможностями смогут только те пользователи, кто имеет возможность пройти аутентификацию на SSH-сервере. Но тем не менее стоит учитывать подобные риски при планировании обеспечения сетевой безопасности корпоративной сети.
