Security

Как защитить общедоступный сервер удаленного рабочего стола?

Мне нужно открыть доступ к моему серверу удаленных рабочих столов (Terminal Services) извне нашей сети. Сейчас доступ к нему возможен только изнутри нашей сети. Я знаю, что достаточно просто открыть брандмауэр и пробросить порт.

Однако как мне необходимо защитить саму машину и каковы лучшие практики в этой области? Меня беспокоит то, что хакеры могут взломать ее. Любые руководства/рекомендации по лучшей практике были бы очень признательны.

Фильтр входящих RDP-подключений по IP, MAC-адресу, имени компьютера и т. д.

Может ли кто-нибудь прокомментировать безопасность этого продукта? Похоже, что я также могу использовать его для ограничения доступа по имени машины. Кто-нибудь еще использовал это?

Ответ 1

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

Мы недавно начали использовать RD Gateway Manager с Remote Desktop Services. Мы настроили его так, чтобы он проходил через наш сервер TMG и напрямую на машину пользователя. Он использует NLA, как упоминалось выше. Подключающийся пользователь должен быть членом нужной группы AD и членом нужной локальной группы, чтобы получить доступ. В зависимости от того, как вы хотите его настроить, вы можете подключиться через веб-страницу, которая просто открывает mstsc и вводит настройки прокси для шлюза RD, или вы можете установить настройки на своей машине вручную, чтобы каждый раз, когда вы открываете ее, она пыталась пройти через этот прокси. До сих пор это работало достаточно хорошо и кажется безопасным.

Ответ 2

Как показала недавняя история, раскрытие протокола сопряжено с определенными рисками. Но есть некоторые шаги, которые вы можете предпринять для защиты системы:

  1. Обеспечьте аутентификацию на сетевом уровне.

  2. Обеспечьте шифрование соединений.

  3. Ограничьте круг пользователей, которым разрешен вход в систему через Terminal Services, до абсолютного минимума, не разрешайте «специальные» учетные записи, такие как стандартная учетная запись администратора домена, или, в идеале, любые другие учетные записи с высокими привилегиями.

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

Ответ 3

Это не очень безопасно, однако есть несколько способов усилить безопасность.

Запретите доступ в интернет с этого сервера. Многие из наиболее серьезных вредоносных программ пытаются связаться со своим командным и управляющим сервером, когда они компрометируют вашу систему. Настройка правила доступа брандмауэра, запрещающего исходящий доступ по умолчанию, и правила, разрешающего исходящий доступ только к внутренним/известным сетям и подсетям RFC 1928, может снизить риск.

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

Настройте периметр сети, разместите сервер удаленного рабочего стола в периметре и используйте недорогую VPN для обеспечения доступа. В качестве примера можно привести Hamachi. Обратите внимание, что запрет доступа в интернет из периметральной сети также является хорошей практикой. Если возможно, не предоставляйте полный рабочий стол, а публикуйте приложения, которые им нужны. Если кому-то нужен доступ только к одному приложению, можно настроить «основную программу», которая может быть простой оболочкой-оберткой, обеспечивающей выход из системы при закрытии приложения.

Ответ 4

Я настоятельно рекомендую использовать службу шлюза Remote Desktop. Она дает вам место, где вы можете применять политики относительно того, кто и откуда может подключаться. Это хорошее место для ведения журнала, так что вы можете видеть, кто пытается войти в систему, не просматривая журналы событий отдельных серверов в вашей системе.

Если вы еще не сделали этого, убедитесь, что ваши политики блокировки учетных записей настроены достаточно надежно. RDP даже с NLA и шлюзом дает людям возможность попытаться перебрать пароли. Надежная политика блокировки значительно затрудняет попытки перебора. Установите на системах действующие SSL-сертификаты, чтобы клиент уведомлял конечных пользователей, если кто-то пытается осуществить MITM-атаку.

Ответ 5

Я бы предложил следующие меры:

  1. Измените порт, используемый для подключения к удаленному рабочему столу.

  2. Не используйте общие имена пользователей, а применяйте более сложную политику именования.

  3. Применяйте высокие требования к паролям.

  4. Закройте любой другой неиспользуемый порт извне (входящий).

Дополнительно:

  1. Используйте VPN (CISCO, Open VPN и т. д.), затем подключитесь к серверу, используя внутренний IP.

  2. Используйте вход по смарт-карте, если это возможно.

Ответ 6

Я использую проброс портов ssh для таких вещей и разрешаю аутентификацию только на уровне пользователя, основанную на открытом ключе. Все личные ключи пользователей также должны быть зашифрованы. В Windows Putty делает это хорошо, а pageant облегчает пользователям загрузку их ключей. Если у вас нет серверов Linux/BSD с ssh по умолчанию, вы можете использовать для этого OpenSSH в Cygwin.

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

Ответ 7

Не совсем лучшая практика, но некоторые возможные варианты:

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

  2. Используйте длинные/сложные пароли для всех системных учетных записей.

  3. Измените порт по умолчанию 3389/tcp на какой-нибудь другой, например 26438/tcp.

Добавьте port-knocking (если возможно) на уровне брандмауэра, чтобы потенциальный пользователь rdp сначала должен был посетить какую-то веб-страницу и только потом мог перейти на rdp на вашем сервере.

Схожие статьи

Специалист по информационной безопасности: профессия будущего или нет?
Security

Специалист по информационной безопасности: профессия будущего или нет?

Security

Политики истечения срока действия пароля

Security

Какие существуют векторы атак на пароли, передаваемые по http?

Security

Как предотвратить атаки «нулевого дня»

×