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

В настоящее время ваш вопрос требует руководства по реализации конкретных технологий. Однако в формулировке проблемы не оценивается конкретная угроза, с которой вы сталкиваетесь, поэтому преждевременно разрабатывать решение; в этом отношении вы XY поставили перед нас.

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

Тщательно определите свою проблему

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

• Определите проблему - какую конкретную трудность мы стремимся решить? Сложность должна быть объективной, измеримой проблемой, подкрепленной вескими доказательствами ее существования из наблюдений, сделанных в полевых условиях.
• Определите допущения и ограничения - есть ли конкретные элементы, которые мы можем предположить как находящиеся в определенном состоянии, и есть ли другие условия на предлагаемое решение? Существенное ограничение должно включать прямые затраты на внедрение решения (покупка оборудования, программного обеспечения или время на консультации) и косвенные затраты (внесение изменений в процесс, обучение персонала,компенсируя потерю производительности).

• Выявление участников угроз (для проблем безопасности) - ни одна система или процесс не является на 100% безопасным . Нам необходимо тщательно определить характер всех противников, которые могут начать атаку, чтобы определить, адекватно ли наше решение предотвращает такие атаки. Это относится как к разработке реальных систем физической безопасности, так и к проектированию с учетом технических результатов.

  Например, в своей оценке вы можете учитывать такие факторы, как:

  • Возможности вашего противника - насколько они осведомлены , есть ли у них доступ к определенным ресурсам для помощи в атаке и т. д.
  • Их позиция - есть существенная разница между сценаристом на последней миле жилого интернет-сервиса и субъектом национального государства с доступом к позиции в сети, с которых возможны атаки типа «злоумышленник посередине»

  • Ваш термостат риска и риска - что побуждает актера атаковать вас или вашу организацию конкретно? Например, хранит ли ваша система или обрабатывает конфиденциальные и / или привилегированные данные, которые обычно носят ограниченный характер и могут представлять ценность для других (личные данные, секреты компании и т. Д.)? Имеет ли он привилегированное положение в сети, из которой может быть запущен дальнейший анализ или атаки (например, основной маршрутизатор у провайдера, пограничный шлюз на периметре чувствительной сети в большой корпорации)?

    Это помогает определить, есть ли мы имеем дело с актером Advanced Persistent Threat (APT), который стремится нацелить на вас конкретно, или мы защищаем оппортунистов. Гораздо легче защититься от мимолетного оппортуниста, имея скромные средства защиты, которые заставят вас выглядеть в безопасности по сравнению с конкурентами.

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

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

На протяжении всего процесса мы помним, что безопасность - это процесс, а не пункт назначения . Мы не можем «покупать» ценные бумаги как готовый товар, и любой, кто предлагает это, лжет или имеет скрытые (вероятно, денежное обогащение) мотивы.

Ваша конкретная проблема

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

Проблема

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

Конкретная проблема - это компромисс в прошлом. машины, с которой вы хотите свести к минимуму любые повторения.

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

Допущения и ограничения

Давайте задокументируем эти моменты, чтобы направить наше решение:

• Службы общедоступного веб-сайта, предоставляемые с машины безопасны
• Рабочие станции, с которых вы инициируете удаленные соединения, не являются прокси-серверами для атаки на рассматриваемый сервер. Например, они сами не проникают (поэтому они не являются вектором утечки или модификации ключей, или двоичных файлов, используемых для создания соединений, которые можно подделать). Вы можете исследовать слабые места в безопасности любых клиентских машин по отдельности или объединить их в одну оценку.
• Серверная машина физически защищена, и вмешательство в конфигурацию оборудования или программного обеспечения со стороны лица, физически обслуживающего машину, маловероятно или исключено . (Машина, к которой злоумышленник имел физический доступ, вряд ли больше будет вашей машиной.)
• Сеть считается скомпрометированной. Могут быть субъекты, которые имеют возможность перехватывать или переадресовывать наши пакеты.
• Мы хотим использовать свободно доступное программное обеспечение для достижения технических аспектов нашего решения.
• Мы предполагаем, что пользователи должным образом обучены таким образом, чтобы атаковать программное обеспечение. (люди-операторы) можно не учитывать (например, угрозы социальной инженерии). Опять же, в принципе, они редко адекватно смягчаются и являются слабым местом для большинства организаций, но это сбой сервера, поэтому, помимо краткого упоминания, я не буду учитывать нетехнические аспекты модели атаки.
• Это приемлемо, если решение требует решения. автономное распространение или проверка ключей перед первым подключением.
• Предполагается, что хорошо известные криптографические примитивы невосприимчивы к бэкдору или непублично раскрытым атакам.

Модель угроз

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

Реализация

Давайте разработаем решение, отвечающее нашим целям. Чтобы обезопасить машину, нам нужно рассмотреть публичные маршруты атак. Он предоставляет две службы, и мы предположили, что веб-служба не уязвима. Следовательно, мы должны рассмотреть подключение удаленной оболочки.

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

Как SSH соответствует нашим целям?

Secure Shell (SSH) предназначен для обеспечения конфиденциальности. и целостность удаленных сеансов оболочки. Это делается с использованием криптографических подходов; в частности, хостам назначается один или несколько ключей хоста, которые могут использоваться для точной идентификации хоста для подключения клиентских машин.

Атаки типа «злоумышленник посередине» на SSH

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

Поскольку нас беспокоит MitM, мы должны разработать решение чтобы смягчить это. Вам доступны следующие варианты (не исчерпывающие):

• Подключение только через доверенные сети. Это не работает, поскольку не соответствует нашим целям или предположениям относительно подключений через общедоступные сети.
• Распространение отпечатка ключа хоста (или его всего открытого ключа) до первоначального подключения. Используйте команду ssh-keygen на сервере, чтобы получить отпечаток пальца, передать его пользователям и попросить их сравнить отпечаток пальца, представленный при первом подключении, с версией на сервере. Они должны войти в систему только в том случае, если совпадают отпечатки пальцев.
• Опубликуйте ключи хоста в DNS и подпишите зону с помощью DNSSEC. Убедитесь, что все подключающиеся клиенты используют распознаватель с проверкой DNSSEC, и проверьте ключи хоста на основе DNS. Дополнительная информация здесь . Такой подход позволяет избежать бремени распространения и ручной проверки ключа хоста, но требует наличия определенных технических компонентов, которые пока не распространены во многих сетях.

Парольные атаки методом перебора

Другая уязвимость работающего демона SSH - это атаки перебора паролей. Злоумышленники часто проверяют ваш ящик на наличие служб SSH и пытаются выполнить аутентификацию, используя общий список имен пользователей и паролей. Ящики с именами пользователей в публичном списке и ненадежными паролями могут быть скомпрометированы. Методы для смягчения этого включают:

• Переключение демона SSH на использование аутентификации на основе ключей и отключение аутентификации по паролю из общедоступного Интернета. Сгенерируйте пару ключей RSA для своей учетной записи с помощью ssh-keygen с большим (например,> 2048) числом бит или подходящим числом бит для пары ключей, подписанной с помощью другой криптосистемы.
• Использование программного обеспечения. например fail2ban , чтобы следить за вашими журналами и добавлять правила брандмауэра, чтобы блокировать дальнейшие попытки подключения с того же адреса после достижения порога неудачного входа в систему.

Поможет ли VPN?

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

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