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

Question

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

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

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

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

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

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

Например, при оценке вы можете учитывать такие факторы, как:
- Возможности вашего противника– насколько они осведомлены, имеют ли они доступ к определенным ресурсам, помогающим атаковать и т. д.
- Их позиция– существует существенная разница между скрипт-кидди на последней миле домашнего интернет-сервиса и субъектом национального государства, имеющим доступ к позициям в сети, с которых возможны атаки типа «человек посередине»
- Твойриск и термостат риска– что мотивирует субъекта атаковать именно вас или вашу организацию? Например, хранит ли или обрабатывает ли ваша система конфиденциальные и/или привилегированные данные, которые обычно имеют ограниченный характер и могут представлять ценность для других (персональные данные, корпоративные секреты и т. д.)? Имеет ли она привилегированное положение в сети, из которого может быть запущен дальнейший анализ или атаки (например, основной маршрутизатор у интернет-провайдера, пограничный шлюз на периметре чувствительной сети в крупной корпорации)?
  
  Это помогает определить, имеем ли мы дело с субъектом повышенной постоянной угрозы (APT), который стремится атаковатьтыконкретно, или защищаем ли мы оппортунистов. Гораздо проще защищаться от проходящего оппортуниста, имея скромную защиту, которая позволяет вам выглядеть защищенным по сравнению с конкурентами.
  
  Кроме того, определение вашей склонности к риску (вашейтермостат риска) способствует оптимизации результата для надлежащего покрытия выявленных рисков без превышения лимита.
Решение о реализации– используя информацию, собранную в ходе этого процесса, принимая во внимание описанные ограничения и нашу позицию относительно риска, определить подходящую технологиюи процессизменения для устранения проблемы,или пересмотреть ограничения или профиль риска, если решение не может быть найдено.

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

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

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

Проблема

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

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

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

Предположения и ограничения

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

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

Модель угрозы

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

Выполнение

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

Для этой цели,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, вероятно, несет дополнительный риск, будучидругойдемон, работающий на вашем компьютере, и более масштабный вектор атаки.

Answer 1

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

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

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

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

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

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

Например, при оценке вы можете учитывать такие факторы, как:
- Возможности вашего противника– насколько они осведомлены, имеют ли они доступ к определенным ресурсам, помогающим атаковать и т. д.
- Их позиция– существует существенная разница между скрипт-кидди на последней миле домашнего интернет-сервиса и субъектом национального государства, имеющим доступ к позициям в сети, с которых возможны атаки типа «человек посередине»
- Твойриск и термостат риска– что мотивирует субъекта атаковать именно вас или вашу организацию? Например, хранит ли или обрабатывает ли ваша система конфиденциальные и/или привилегированные данные, которые обычно имеют ограниченный характер и могут представлять ценность для других (персональные данные, корпоративные секреты и т. д.)? Имеет ли она привилегированное положение в сети, из которого может быть запущен дальнейший анализ или атаки (например, основной маршрутизатор у интернет-провайдера, пограничный шлюз на периметре чувствительной сети в крупной корпорации)?
  
  Это помогает определить, имеем ли мы дело с субъектом повышенной постоянной угрозы (APT), который стремится атаковатьтыконкретно, или защищаем ли мы оппортунистов. Гораздо проще защищаться от проходящего оппортуниста, имея скромную защиту, которая позволяет вам выглядеть защищенным по сравнению с конкурентами.
  
  Кроме того, определение вашей склонности к риску (вашейтермостат риска) способствует оптимизации результата для надлежащего покрытия выявленных рисков без превышения лимита.
Решение о реализации– используя информацию, собранную в ходе этого процесса, принимая во внимание описанные ограничения и нашу позицию относительно риска, определить подходящую технологиюи процессизменения для устранения проблемы,или пересмотреть ограничения или профиль риска, если решение не может быть найдено.

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

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

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

Проблема

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

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

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

Предположения и ограничения

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

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

Модель угрозы

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

Выполнение

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

Для этой цели,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, вероятно, несет дополнительный риск, будучидругойдемон, работающий на вашем компьютере, и более масштабный вектор атаки.

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

решение1

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

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

Проблема

Предположения и ограничения

Модель угрозы

Выполнение

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

Атаки «человек посередине» на SSH

Атаки методом подбора пароля

Поможет ли VPN?

Связанный контент