IP лог RDP соединений

[Plague]

Вот уж чего не ожидал, так это того, что здесь могут быть проблемы.
Итак.
Сервер 2008R2.
В свойствах удалённого доступа (Панель управления\Все элементы панели управления\Система - доп.параметры - удалённый доступ) выбран третий переключатель, как рекомендуется. Насколько я понимаю, вторая и третья позиции - есть переключение между протоколами авторизации и доступа User32/NTLM.
В политиках безопасности (gpedit.msc - конфигурация компьютера - параметры безопасности - локальные политики - политика аудита) Аудит входа в систему вглючен и на отказ и на успех. и до кучи тоже самое, там же и для "Аудит событий входа в систему".

После чего идем в просмотр событий - журналы windows - безопасность.
При успешном входе (код события 4624) IP успешно записывается. (только поздно пить боржоми если почки отвалились)
При отказе (Неизвестное имя пользователя или неверный пароль, код события 4625) эта зараза записывает Имя рабочей станции - читает даже извне, не только из локальной сети (только накой хрен оно нужно), но не считает нужным записать его IP.

Копание в интернетах навело на сей совет:

These are the GPO settings I set that did the magic. Please note that this is a Server 2008 R2 box.

Required
Computer Configuration\Windows Settings\Security Settings\Security Options

Network security: LAN Manager authentication level -- Send NTLMv2 response only. Refuse LM & NTLM
Network security: Restrict NTLM: Audit Incoming NTLM Traffic -- Enable auditing for all accounts
Network security: Restrict NTLM: Incoming NTLM traffic -- Deny all accounts

Recommended
Do not allow for passwords to be saved -- Enabled
Prompt for credentials on the client computer -- Enabled

I changed some other security-related keys, too, but these should be the core ones. Forcing incoming network traffic away from using NTLM allows every single 4625 event to contain the IP Address of the failed computer, as they are force to use User32 logon.

Всё работает. В случае, если переключиться на более древний User32, о чем там и сообщается. В случае же с NTLM (третий переключатель в свойствах RDP) при настройке по этому совету, к компу по RDP вообще зацепиться нельзя, что логично, ибо:

Network security: Restrict NTLM: Incoming NTLM traffic -- Deny all accounts

Упреждая советы переключить RDP в User32 скажу что:

1. Майкрософт сама не рекомендует юзать его.
2. При вглючении оного неудачный логин происходит по следующему сценарию: RDP открывает окно, а уже в этом окне сообщает о неверности логина/пароля, что лично мне категорически не нравится. Бред какой-то . NTLM же просто тупо отшибает сразу, что более правильно.

PS. есть софтина Cyberarms Intrusion Detection которая замечательно всё это логирует, и даже банить умеет , вопрос в том что во-первых, я хочу понять, кто из нас идиот: я (потому что не могу найти едва ли не основной фундамент безопасности - IP-лог попыток входа в систему) или Майкрософт (которые не считают нужным этот лог писать ); ну, и во-вторых, если есть возможность сделать что-то штатными средствами, то нужно это делать штатными средствами, а не развешивать лишнюю клюкву…

[Borland]

Поковырялся в этих ваших гуглях.
Лучший из найденных советов не выставлять в интернет RDP (в чистом виде) вообще...
Если очень нужно - сначала подключать VPN, а уже внутри VPN устанавливать RDP-соединение с использованием логина/пароля (а ещё лучше - прикрутить дополнительно аутентификацию при помощи "смарт-карты"/e-token).
Сам по себе RDP изначально предназначен именно для использования внутри {доверенной} LAN, и именно отсюда "растут ноги" его проблем с безопасностью...

Почти оффтоп:

Собственно, толстым намёком на этот фак(т) служит само наименование протокола NTLM, в котором "L" означает "LAN"...

Ну и, если уж без доступа извне никак - желательно ещё и резать (файрволлом) вообще все попытки доступа извне к защищаемому ресурсу со всех IP, кроме доверенных...

Сообщение от Plague

есть софтина

Есть не очень маленькое количество как программных, так и программно-аппаратных IDS/IPS (Intrusion Detection/Prevention System) на любой вкус и кошелёк...
Но это отнюдь не отменяет необходимости максимально "прятать" уязвимые протоколы в туннели со стойким шифрованием и, по возможности, максимально "ограничивать круг общения" даже с использованием этих туннелей...

[Plague]

IP в логах - отнюдь не лишний параметр даже для локальных сетей.
я так понимаю, что в этом смысле твои изыскания ничем от моих не отличаются. плохо...

[Borland]

Сообщение от Plague

IP в логах - отнюдь не лишний параметр даже для локальных сетей.

IP как таковой в локальной сети, раз уж злоумышленник туда вообще попал, подменяется "одной левой" вкупе с MAC; в отличие, к примеру, от авторизации по доменному SID.
А в качественной доверенной LAN осуществляется жёсткая привязка MAC к порту коммутатора (при этом комп, в принципе, запросто обходится динамическим IP), причём в любой момент времени точно известно физическое местоположение розетки СКС, которая скоммутирована в этот порт. Соответственно, единственный способ для нелегального устройства подключиться к такой сети - отключение легального устройства и коммутация в его порт с подменой MAC. А от этого достаточно надёжно защищают вполне себе оффлайновые методы ограничения физического доступа в помещения...
И в такой сети имя компа, с которого осуществляется доступ по RDP, однозначно указывает и на физическую точку, с которой осуществляется доступ, и на лицо, этот доступ осуществляющее. Посему имени компа в логе вполне достаточно.
А при доступе через VPN за авторизацию устройства в LAN и отвечает, собственно, VPN.

В общем, резюмируя: RDP не предполагает наличия встроенных элементов IDS "by design", полагаясь в этом на другие средства.
И, как я уже говорил, для доступа клиента из тырьнета по RDP нужно применять дополнительные средства защиты. Если клиент авторизовался через VPN, то уже сразу ясно, "кому бить морду" и "за что": за то, что забыл свой пароль (что, в принципе, простительно) или за попытку взлома чужого. Ну, либо за компроментацию (путём слива третьим лицам) ключей доступа...

[Plague]

если RDP не предназначен для доступа из глобальных сетей, то накой в евойном клиенте настройки оптимизации для ширины канала? (вкладка "взаимодействие", в коей присутствуют как сети модемного, так и спутникового соединения)
впрочем, тут конечно можно парировать тем, что модемное соединение - не обязательно соединение с интернет-провайдером, оно может быть и "точка-точка". И я сам в начале века, помнится, им пользовался (правда, не для RDP).
С вариантом спутника - тут мне кажется, уже разночтений меньше.
Кстати, надо покурить последнюю вкладку настроек (Дополнительно - Подключение из любого места), может если рульнуть это хозяйство через какой-то специательный шлюз, он будет более внимателен к наблюдению за проходящими соединениями... Хотя, в этом случае, сие - тоже "дополнительная клюква", только другого цвета...

[Plague]

Сообщение от Plague

надо покурить последнюю вкладку настроек (Дополнительно - Подключение из любого места)

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

Из "заморочек" - обязательное внесение сертификата безопасности шлюза в хранилище доверенных центров сетификации клиента, что само по себе являясь нетривиальной для рядового клерка задачей, порождает так же и некоторые заморочки для админа, как то: сертификат должен быть сконфигурирован для того адреса по которому будет обращение клиентом, поэтому соответствие имени тестового сервера "win2008" (на который был сгенерён сертификат) IP-адресу, на тестовой удалённой клиентской машине мне пришлось добавлять в файл hosts. Во-вторых, я почему-то не нашёл ни в одном руководстве по конфигурированию шлюза упоминания о том, что группа "Администраторы" не подходит для разрешения в политике доступа к шлюзу (хотя по умолчанию добавляется именно она), и я вчера пол-вечера как дятел долбился в него и читал интернеты, пытаясь понять почему не работает. Так же, нигде не написано что при вводе пароля для шлюза нужно обязательно ставить галку "запомнить". Иначе меня не пускало ни при каких обстоятельствах. В общем, заморочек сильно больше, чем дохрена, и в случае если нет целого NAT-парка машин с RDP, нафик оно не нужно. Проще заюзать мной выше упомянутую банилку, и не париться.