Як убезпечити загальнодоступну сервер віддаленого робочого столу?

Я розглядаю необхідність відкрити мій сервер віддаленого робочого столу (послуги терміналів), до якого можна отримати доступ за межами нашої мережі. Зараз до нього можна отримати доступ лише з нашої мережі.

Я знаю, що досить просто відкрити брандмауер та переслати порт.

Однак як я закріплюю сам апарат і які найкращі практики щодо цього? Моє занепокоєння полягає в тому, що хакери зможуть працювати над їх вторгненням.

Будь-які вказівки та рекомендації щодо найкращої практики були б вдячні.

Редагувати:

Питання про товар, який я знайшов:

Фільтруйте вхідні з'єднання RDP за IP, MAC-адресою, іменем комп'ютера та іншим

Хтось може прокоментувати безпеку цього? Схоже, я міг би також використовувати його для обмеження доступу за назвою машини / mac? Хтось ще користувався ним?

Це може бути більше ніж те, що ви хочете зробити, але ось як ми використовуємо RDP для віддалених користувачів, які не використовують VPN.

Нещодавно ми почали використовувати диспетчер шлюзів RD із службами віддаленого робочого столу, роль у Windows 2008. У нас він налаштований перейти через наш сервер TMG та безпосередньо на машину користувачів. Він використовує NLA, як згадувалося вище. Користувач, який підключається, повинен бути членом правої групи AD, а членом правої локальної групи, щоб отримати доступ. Залежно від способу налаштування, ви можете підключитися через веб-сторінку, яка в основному відкриває mstsc і вводить налаштування проксі для шлюзу RD, або ви можете встановити настройки на вашій машині вручну, так що кожен раз, коли ви відкриваєте її, вона намагатиметься перейти. через цей проксі. Поки що він працював досить добре і, здається, захищений.

Як показала недавня історія , існують властиві ризики викриття протоколу. Але є кілька кроків, які ви можете зробити для захисту системи:

• Закріпити автентифікацію на рівні мережі.
• Закріпити шифрування з'єднання.
• Обмежте користувачів, дозволених входити в службу терміналів, до абсолютного мінімуму, і не дозволяйте "спеціальні" акаунти, такі як Administratorобліковий запис домену за замовчуванням , або в ідеалі будь-які інші облікові записи з високими привілеями.
• Переконайтеся, що паролі надійні в облікових записах, на які дозволяється входити. Залежить від кількості користувачів і того, як зараз виглядає ваша політика, але викидаєте хеші та намагаєтесь їх зламати, збільшуючи обмеження щодо довжини пароля або просто навчаючи користувачів. хороші підходи.

Настійно пропоную скористатися послугою шлюзу віддаленого робочого столу. Це дає вам місце, де ви можете застосовувати політику щодо того, хто може підключитися до того, з чого. Це дає вам гарне місце для ведення журналів, тож ви можете бачити, хто намагається ввійти, не перевіряючи журнали подій окремих серверів у вашому господарстві.

Якщо ви цього ще не зробили, переконайтеся, що політика блокування облікового запису налаштована досить сильно. RDP навіть з NLA та шлюзом дають людям щось, щоб спробувати жорстоке примушування паролів. Сильна політика блокування значно ускладнює успіх грубих спроб досягти успіху.

Встановіть дійсні сертифікати SSL в системах, тому клієнт сповістить кінцевих користувачів, якщо хтось намагається здійснити якусь атаку MITM.

Це не дуже безпечно, однак є кілька способів посилити безпеку.

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

Використовуйте смарт-карти або інший тип двофакторної аутентифікації. Це, як правило, дорого і знаходиться в основному у великих організаціях, однак варіанти вдосконалюються (на розум приходить PhoneFactor). Зауважте, що потрібні смарт-картки можуть бути виконані на одному сервері, як варіант налаштування на рівні облікового запису.

Налаштуйте мережу периметра, розмістіть віддалений сервер настільних ПК по периметру та використовуйте недорогий VPN для надання доступу. Прикладом може бути Хамачі. Зауважте, що заборона доступу до Інтернету з мережі периметра також є хорошою практикою.

Якщо можливо, не надайте повний робочий стіл, але публікуйте необхідні програми. Якщо комусь потрібен лише доступ до однієї програми, можна також налаштувати "початкову програму", яка може бути простою оболонкою для обгортки, яка може застосувати вихід із системи, коли програма закривається.

Я б запропонував такі заходи:

1. Змініть порт, який використовується для підключення до віддаленого робочого столу
2. Не використовуйте загальні імена користувачів, а більш складну політику іменування
3. Високі вимоги до паролів
4. Закрити будь-який інший невикористаний порт ззовні (вхідний)

За бажанням

5. Використовуйте VPN (CISCO, Open VPN тощо), а потім підключіться до сервера за допомогою внутрішнього IP-адреси.
6. Якщо можливо, використовуйте вхід із смарт-карт

Ви можете запустити WinSSHD на порт 22, а потім використовувати клієнт Tunnelier, щоб створити для вас тунель і автоматично відкрити сеанс обслуговування терміналів через тунель одним натисканням кнопки. Це також дає вам дуже хороший безпечний варіант FTP, а також для передачі файлів.

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

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

Bitvise SSH - це хороший безкоштовний SSH для Windows.

Я б хотів придбати дешеве завершення SSL VPN від клієнта до периметру шлюзу для Інтернету, інакше, ніж для випадкового використання (наприклад, комерційний невпевненість).

Вищенаведені публікації щодо забезпечення RDP також є хорошою практикою, і їх слід завжди виконувати, якщо ви не хочете ділитися своїми комп’ютерами з безкоштовними навантажувачами.

не дуже найкраща практика, але кілька випадкових думок:

• постійно оновлюйте систему - дозволяйте автоматичні оновлення, не використовуйте продукти, які закінчуються,
• використовувати довгі / складні паролі для всіх облікових записів системи
• Мене тут знущаються за те, що я запропонував "безпеку через незрозумілість", але це не принесе вам шкоди, якщо ви:
  • змінити стандартний порт 3389 / tcp на щось інше, наприклад, 26438 / tcp
  • додайте стукіт порту [якщо можливо] на рівні брандмауера, щоб потенційний користувач rdp спершу зайшов на якусь веб-сторінку і лише потім зможе rdp на ваш сервер.