MSTSC RDP через общедоступный интернет
Мой первый вопрос, поэтому, пожалуйста, будьте нежны:)
У меня есть клиент, который настаивает на том, что он должен разрешить стороннему поставщику поддерживать доступ к этому серверу напрямую из Интернета через RDP.
Наша политика не допускает прямого доступа к инфраструктуре за пределами центра обработки данных для администрирования, кроме как через утвержденное VPN-подключение, а затем через виртуальный рабочий стол на серверах.
Сейчас я нахожусь в ситуации, когда я должен привести веские причины, по которым использование RDP через общедоступный Интернет опасно.
любая помощь будет оценена
заранее спасибо
Стюарт
6 ответов
Не забывайте, что злоумышленник, который подвергает риску этот сервер, также может использовать его как трамплин для атаки на объекты других клиентов за брандмауэром. Таким образом, риск безопасности не ограничивается только активами первого клиента.
Получите некоторое обоснование от продавца относительно того, почему они не могут использовать VPN. Если действительно нет альтернативы подключению RDP напрямую к серверу, то они должны взять на себя ответственность за любые нарушения безопасности через это соединение. Имейте в виду, что поставщик только что признал недостатки безопасности в своей архитектуре приложения, заявив, что в приложении есть что-то, что препятствует использованию VPN.
Сделайте доступ условным при подписании соглашения, освобождающего вас от любого ущерба, вызванного взломом безопасности через соединение RDP. Кроме того, вы должны потребовать, чтобы они получили соответствующее профессиональное возмещение или покрытие ответственности или предоставили доказательство существующего покрытия с условиями, которые бы охватили эту ситуацию.
Короче говоря, заставьте поставщика доказать, что он может позволить себе заплатить за любой ущерб, и сделать свой доступ обусловленным договорным обязательством сделать это.
Большинство людей, у которых есть проблема с разрешением RDP напрямую из Интернета, испытывают особый интерес к идее, что злоумышленники напрямую запрашивают ваш каталог / SAM для проверки подлинности. Без надлежащего аудита это часто остается незамеченным. После того, как они успешно получили одну пару входа в систему, они имеют запрещенный доступ к вашей среде. Ответ Microsoft на это пришел с Windows 2008 в форме TS-Gateway. Сервисы TS-Gateway создают точку туннеля, не похожую на установку туннеля SSL VPN. Служба шлюза TS, когда он все еще использует один и тот же каталог или SAM для аутентификации, предоставляет отдельный набор правил авторизации, которых раньше не было. Правила как на уровне пользователя, так и на уровне компьютера могут быть установлены для управления доступными вам ресурсами после аутентификации в шлюзе TS. Итак, 1 вам не нужно настраивать внешние DNS-сопоставления имен для всех ваших внутренних серверов и 2 вы можете ограничить определенных пользователей (групп пользователей) конкретными системами.
I have also done implementations where TS-Gateway access users are a separate account from those that have access to the internal servers. With a much higher password expiration and lockout on the TS-Gateway accounts. This provides one more layer for those paranoid about direct pass through authorization. It also works well for groups with specific business policy regarding DMZ systems being a member of an internal domain.
My biggest problem (as with others) with TS-Gateway thus far is it's lack of support for two-factor auth options for the initial gateway connection. The second biggest being the lack of client support for TS-Gateway.
However in your case assuming your external vendor agrees to use a 6.1 compliant RDP client and you take care in your setting up of a proper TS-Gateway server there should be little reason why the request should pose a threat.
Недавно я заменил умирающий маршрутизатор D-Link (DI-524) на Cisco / Linksys RSV4000. Я действительно доволен устройством, но, кажется, когда к нему подключен мой кабельный модем, я теряю 1/3 скорости загрузки. Когда я подключаю модем прямо к своему рабочему столу, у меня снижается скорость на 30 Мбит / с, а на 5 Мбит / с выше, но при прохождении через маршрутизатор у меня снижается скорость 20 Мбит / с.
У меня была такая проблема на работе, когда мы переключились на Comcast, поскольку их служба поддержки не работала с прокси-сервером http на нашем брандмауэре Watchguard. Поэтому я попытался отключить все параметры в маршрутизаторе, чтобы увидеть, как это повлияет, но это ничего не изменило. У меня никогда не было этой проблемы со старым D-Link.
Кто-то сказал, чтобы проверить мой MTU и изменить его на 1400 с 1500, но это ничего не сделало ни на маршрутизаторе, ни на настольных компьютерах.
Даже если RDP настроен на использование шифрования, вы все равно разрешаете прямой доступ к вашему серверу. Если у вас есть брандмауэр и вы позволяете IP-адресу вашего поставщика подключаться только к порту RDP, это может быть нормально, но если вы оставляете его открытым с любого IP-адреса, это опасно, если в течение дня на RDP возникают проблемы с безопасностью.
Я рекомендую использовать VPN-шлюз как Cisco ASA с доступом через WEB SSL VPN. Затем веб-портал позволяет перенаправить порт на удаленный сервер, или, что еще лучше, вы можете запустить апплет RDP (directx или java) на портале. Это решение является более безопасным и работает без какого-либо vpn-клиента, установленного на компьютере поставщика. Просто нужен браузер с поддержкой SSL и Java или DirectX
Я слышал, что есть новая технология только для Windows 2008 R2, которая называется "Прямой доступ", это, по сути, встроенная в ОС VPN через SSL, я думаю, что она требует Windows 2008 R2 и Windows 7 в качестве клиента, но это другая вариант и может быть дешевле, чем инвестировать в другое решение, такое как F5 или Cisco.
Поскольку вы используете хотя бы RDP 6.0, я не вижу в этом ничего плохого. Некоторые из моих TS-серверов открыты для доступа через Интернет, но обеспечивают безопасность только 6.0 (с TLS и в XP).