Подключение к рабочему столу Windows через VPN-подключение

• Вопрос

• Доброго времени суток! В локалке есть шлюз, W2k8R2, это просто шлюз, куда приходит инет с двумя сетевыми интерфейсами, на которых прописаны белые IP двух моих провайдеров. Один резервный, другой постоянный. На шлюзе есть TMG2010 и WSUS. Всё. Единственная станция, на которой не был установлен антивирус, но 5 лет назад, когда этот сервер поднимали, вроде и не было такой необходимости, — он был поднят, настроен, и забыт на все эти годы. TMG2010 вполне хватало….Ну иногда я подключался к нему, внести изменения в файерволе, и всё.  После установки обновлений он сам перезапускался  в 3 часа ночи.  Проблема, — периодически, в любое время суток производится блокировка учётных записей в AD из-за неверно введённых паролей.  Решил поставить на него дополнительно недавно актуальный антивирус. Блокировки прекратились, на некоторое время, и потом снова появляются, правда, уже меньше  в разы!  В отчётах модуля «Защита от сетевых атак» мама не горюй, событий. В основном вот эта дрянь стучится, — Bruteforce.Generic.RDP   Почитал про него, и в самом деле, — именно подбор паролей через RDP…. Все IP, с которых он лезет, естественно, левые, не мои. DNS имена атакующих станций, — тоже не мои. Менял внешний IP, — через сутки, примерно,  снова всё начинается. Если тупо вытащить кабель из сетевой карты с внешним айпи, — то блокировок нет вообще, но и интернет тоже, как вы понимаете, отсутствует. А это не айс!)) По RDP извне официально подключаются трое пользователей. Поэтому, он всё таки нужен. Это если предложите отключить!)))) Есть мысль организовать  VPN, и уже через него подключаться по RDP.  Я не сталкивался по работе с VPN, ну разве что, примитивно организовывал  vpn-подключение средствами Windows  по предоставленным мне учётным данным. Можно какой то мануал по этому поводу, если есть , конечно! Что посоветуете? Как защититься от проникновений извне? Есть ли какое то серверное решение? Не хочется пользоваться сторонними продуктами типа SafeRDP…  Благодарю.

  Adios Amigos

  26 апреля 2017 г. 9:56 Ответить | Цитировать

Ответы

• День добрый!

  Настройте на TMG Настройка удаленного доступа по VPN для удаленного клиента

  Если Вам помог чей-либо ответ, пожалуйста, не забывайте жать на кнопку «Предложить как ответ» или «Проголосовать за полезное сообщение»

  • Помечено в качестве ответа28 апреля 2017 г. 11:08

  27 апреля 2017 г. 12:38 Ответить | Цитировать

• Cложновато для моего понимания!)))

  :))) Imho, если доставить «шлюз RDP» и начать его настраивать, всё прозрачно. Создаётся политика авторизации подключений — кто вообще может куда-то подключаться (к RDP) через этот шлюз. И политика авторизации ресурсов — кто может подключаться к конкретным (указанным) целевым системам. И только когда предъявляемый логин и целевая система политикам соответствуют, происходит попытка аутентификации.

  У вас подключаются извне трое (и, наверное, не к любым внутренним системам) — организовать соответствующие политики «на троих», при наличии попыток подключения под любыми иными учётками, для них просто не будет попыток аутентификации, соответственно, не будет и блокировок.

  Кроме того, подключения происходят по SSL, и для успешного подключения на системе клиента должно быть обеспечено доверие сертификату шлюза. Если там «свой» сертификат, множество юных кулхацкеров отсеиваются уже на этом этапе 😉

  P.S. В клиенте RDP шлюз для подключения указывается на вкладке «Дополнительно -> Параметры».

  S.A.

  • Помечено в качестве ответа28 апреля 2017 г. 11:09

  28 апреля 2017 г. 8:47 Ответить | Цитировать

• В опсчем-с, я поступил иначе. У актуального антивируса, помимо модуля «Защита от сетевых атак» есть модуль — «Сетевой экран», я в нём, в разделе «Сетевые пакетные правила» создал три правила для моих трёх внешних RDP- подключений. И всё. Итак:

   

  Adios Amigos

  • Помечено в качестве ответа28 апреля 2017 г. 11:54

  28 апреля 2017 г. 11:53 Ответить | Цитировать

Все ответы

•  Здравствуйте,

  Если правильно понял вас проблема из-за неверно введенных паролей производится блокировка УЗ в AD. И вы решили вопрос поставив актуального антивируса и в отчетах нашли причну такова поведения, а именно Bruteforce.Generic.RDP ?

  27 апреля 2017 г. 9:45 Ответить | Цитировать

• Всё верно.

  Adios Amigos

  27 апреля 2017 г. 9:47 Ответить | Цитировать

• День добрый!

  Настройте на TMG Настройка удаленного доступа по VPN для удаленного клиента

  Если Вам помог чей-либо ответ, пожалуйста, не забывайте жать на кнопку «Предложить как ответ» или «Проголосовать за полезное сообщение»

  • Помечено в качестве ответа28 апреля 2017 г. 11:08

  27 апреля 2017 г. 12:38 Ответить | Цитировать

• … По RDP извне официально подключаются трое пользователей. Поэтому, он всё таки нужен. Это если предложите отключить!)))) Есть мысль организовать  VPN, и уже через него подключаться по RDP.  …

  В принципе, VPN на TMG поднимается на раз-два, в разнообразных вариантах, вроде и без мануалов понятно :).

  Есть и другой вариант — поднять шлюз RDP и убрать возможность прямых подключений к RDP (только через шлюз). Основной фокус в проверке на соответствие политикам (предварительная авторизация) до аутентификации. При грамотно составленных политиках (какому эккаунту к какой системе подключаться можно) большинство попыток доступа отсеиваются без аутентификации (до), блокировки «популярного набора» учёток не будет. Дополнительный фокус — подключение по SSL/TLS, не каждый из ищущих открытых RDP будет туда ломиться. Компонент «шлюз RDP» на W2k8R2 вполне функционален.

  S.A.

  • Помечено в качестве ответа28 апреля 2017 г. 3:21
  • Снята пометка об ответе28 апреля 2017 г. 3:21

  27 апреля 2017 г. 15:00 Ответить | Цитировать

• … По RDP извне официально подключаются трое пользователей. Поэтому, он всё таки нужен. Это если предложите отключить!)))) Есть мысль организовать  VPN, и уже через него подключаться по RDP.  …

  В принципе, VPN на TMG поднимается на раз-два, в разнообразных вариантах, вроде и без мануалов понятно :).

  Есть и другой вариант — поднять шлюз RDP и убрать возможность прямых подключений к RDP (только через шлюз). Основной фокус в проверке на соответствие политикам (предварительная авторизация) до аутентификации. При грамотно составленных политиках (какому эккаунту к какой системе подключаться можно) большинство попыток доступа отсеиваются без аутентификации (до), блокировки «популярного набора» учёток не будет. Дополнительный фокус — подключение по SSL/TLS, не каждый из ищущих открытых RDP будет туда ломиться. Компонент «шлюз RDP» на W2k8R2 вполне функционален.

  S.A.

  Cложновато для моего понимания!)))

  Adios Amigos

  28 апреля 2017 г. 3:21 Ответить | Цитировать

• День добрый!

  Настройте на TMG Настройка удаленного доступа по VPN для удаленного клиента

  Если Вам помог чей-либо ответ, пожалуйста, не забывайте жать на кнопку «Предложить как ответ» или «Проголосовать за полезное сообщение»

  Как обычно у Майкрософт, — нагромождено всего, не разобраться, что важно на самом деле, а что нет….

  Adios Amigos

  28 апреля 2017 г. 3:22 Ответить | Цитировать

• Cложновато для моего понимания!)))

  :))) Imho, если доставить «шлюз RDP» и начать его настраивать, всё прозрачно. Создаётся политика авторизации подключений — кто вообще может куда-то подключаться (к RDP) через этот шлюз. И политика авторизации ресурсов — кто может подключаться к конкретным (указанным) целевым системам. И только когда предъявляемый логин и целевая система политикам соответствуют, происходит попытка аутентификации.

  У вас подключаются извне трое (и, наверное, не к любым внутренним системам) — организовать соответствующие политики «на троих», при наличии попыток подключения под любыми иными учётками, для них просто не будет попыток аутентификации, соответственно, не будет и блокировок.

  Кроме того, подключения происходят по SSL, и для успешного подключения на системе клиента должно быть обеспечено доверие сертификату шлюза. Если там «свой» сертификат, множество юных кулхацкеров отсеиваются уже на этом этапе 😉

  P.S. В клиенте RDP шлюз для подключения указывается на вкладке «Дополнительно -> Параметры».

  S.A.

  • Помечено в качестве ответа28 апреля 2017 г. 11:09

  28 апреля 2017 г. 8:47 Ответить | Цитировать

• Вот как у вас всё просто 🙂 Прям от клавы отскакивает))) Завидую. По доброму. Ну не дружу я с этим ТМГ, и всё тут… Мне б мануальчик понятный, — вот это моё!))

  Adios Amigos

  28 апреля 2017 г. 11:12 Ответить | Цитировать

• Cложновато для моего понимания!)))

  :))) Imho, если доставить «шлюз RDP» и начать его настраивать, всё прозрачно. Создаётся политика авторизации подключений — кто вообще может куда-то подключаться (к RDP) через этот шлюз. И политика авторизации ресурсов — кто может подключаться к конкретным (указанным) целевым системам. И только когда предъявляемый логин и целевая система политикам соответствуют, происходит попытка аутентификации.

  У вас подключаются извне трое (и, наверное, не к любым внутренним системам) — организовать соответствующие политики «на троих», при наличии попыток подключения под любыми иными учётками, для них просто не будет попыток аутентификации, соответственно, не будет и блокировок.

  Кроме того, подключения происходят по SSL, и для успешного подключения на системе клиента должно быть обеспечено доверие сертификату шлюза. Если там «свой» сертификат, множество юных кулхацкеров отсеиваются уже на этом этапе 😉

  P.S. В клиенте RDP шлюз для подключения указывается на вкладке «Дополнительно -> Параметры».

  S.A.

  Есть нюанс: шлюз RDP (RD Gateway, RDG) на компьютер с TMG, на котором опубликованы по HTTPS внутренние серверы, так просто не поставить — он при настройках по умолчанию будет конфликтовать за порт 443 со службой, которая обеспечивает публикацию (она, к сожалению, не использует системный драйвер http.sys а прослушивает порт самостоятельно). Как установить RDG на сервере TMG в таком случае, я когда-то написал.

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

  Слава России!

  28 апреля 2017 г. 11:50 Ответить | Цитировать

• В опсчем-с, я поступил иначе. У актуального антивируса, помимо модуля «Защита от сетевых атак» есть модуль — «Сетевой экран», я в нём, в разделе «Сетевые пакетные правила» создал три правила для моих трёх внешних RDP- подключений. И всё. Итак:

   

  Adios Amigos

  • Помечено в качестве ответа28 апреля 2017 г. 11:54

  28 апреля 2017 г. 11:53 Ответить | Цитировать

• В случае известного (ограниченного) перечня внешних IP, ограничение возможности подключения соответствующими адресами, наиболее простое и правильное решение.

  Только небольшое уточнение — при наличии TMG, то же самое можно было сделать непосредственно им, в правиле, разрешающем подключения по RDP. Без задействования файрвола «актуального антивируса» и/или любых дополнительных средств вообще :).

  S.A.

  29 апреля 2017 г. 9:26 Ответить | Цитировать

• Согласен с Вами.)) 

  Adios Amigos

  29 апреля 2017 г. 17:30 Ответить | Цитировать