Зачем использовать SSH и VPN в комбинации?

Мой работодатель требует, чтобы я сначала подключился к VPN, и только потом я могу подключиться к SSH. Но, учитывая безопасность SSH, является ли VPN избыточным?

Какая польза от VPN с точки зрения безопасности, если я уже использую SSH ?

Причиной вашей текущей настройки, вероятно, является некоторая комбинация следующих трех причин.

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

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

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

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

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

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

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

Добавление VPN добавляет дополнительный уровень защиты, который контролируется на корпоративном уровне, а не на уровне отдельного сервера, как SSH.

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

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

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

SSH - это протокол шифрования, используемый для нескольких вещей. Шифрование трафика в VPN-туннеле является одним из них. Ваш трафик шифруется с использованием SSH, но затем его необходимо обернуть в действительные IP-пакеты (туннель) для прохождения через сеть, такую ​​как Интернет. Этот туннель является VPN.

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

Вам нужен VPN, чтобы войти в локальную сеть.

После этого вам не нужно защищать ваше соединение с отдельными серверами, так как оно уже будет зашифровано по каналу VPN.

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

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

Вы также можете управлять дополнительными уровнями безопасности через VPN. Например, проверка критериев устройства, двухфакторная аутентификация и т. Д.

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

Если вы исходите из того, что требуются как SSH, так и VPN (для своих собственных целей), то у обоих есть внешняя сторона, что означает, что у злоумышленников есть два возможных маршрута в вашу среду. Если вы делаете SSH только локальным, это добавляет дополнительный уровень безопасности сервера. Рассмотрим следующие сценарии:

1. SSH + VPN внешне. Атакующему нужен только взлом SSH для взлома сервера.

2. SSH внешний. Функционально так же, как и предыдущий сценарий.

3. VPN внешний (SSH внутренний). Удваивается на безопасность. Атакующий должен прорваться через оба, прежде чем они смогут что-либо сделать с сервером.

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

Я бы рискнул, что ответом будет просто то, что NAT задействован и (как уже говорили многие другие), выставляя конечному целевому серверу весь мир, предлагает другую точку атаки. Если вы не выполняете объемную передачу данных с большими ключами, SSH обычно не мешает. Узким местом почти всегда будет сеть. (Почти! = Всегда).

Если вам «повезло» иметь IPv6, это вряд ли будет большой проблемой, но с IPv4 и ограниченным доступным адресным пространством NAT (IMO) в конечном счете, я думаю, что стоит за этой «политикой» больше, чем любая другая. «случайная» или «целенаправленная» безопасность.

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

Однако через VPN-туннель позволяет то, что не делает ssh. Дополнительный предварительно согласованный симметричный ключ шифрования. Это означает, что трафик между двумя компьютерами не восприимчив к человеку, находящемуся в середине атаки, поскольку трафик, если он перехватывается и пересылается от имени аутентичного клиента для управления уровнем шифрования ssl, не сможет передать ключ шифрования vpn. требования, потому что третья сторона не будет иметь возможность подделывать ключи vpn так же, как они могли бы контролировать переадресацию посредником ssh tcp ssl-соединения.

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