Вот уж чего не ожидал, так это того, что здесь могут быть проблемы. Итак. Сервер 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.
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.
The time has come it is quite clear, our antichrist isalmostalready here.
The time has come it is quite clear, our antichrist isalmostalready here.
IP как таковой в локальной сети, раз уж злоумышленник туда вообще попал, подменяется «одной левой» вкупе с MAC; в отличие, к примеру, от авторизации по доменному SID. А в качественной доверенной LAN осуществляется жёсткая привязка MAC к порту коммутатора (при этом комп, в принципе, запросто обходится динамическим IP), причём в любой момент времени точно известно физическое местоположение розетки СКС, которая скоммутирована в этот порт. Соответственно, единственный способ для нелегального устройства подключиться к такой сети — отключение легального устройства и коммутация в его порт с подменой MAC. А от этого достаточно надёжно защищают вполне себе оффлайновые методы ограничения физического доступа в помещения. И в такой сети имя компа, с которого осуществляется доступ по RDP, однозначно указывает и на физическую точку, с которой осуществляется доступ, и на лицо, этот доступ осуществляющее. Посему имени компа в логе вполне достаточно. А при доступе через VPN за авторизацию устройства в LAN и отвечает, собственно, VPN.
В общем, резюмируя: RDP не предполагает наличия встроенных элементов IDS «by design», полагаясь в этом на другие средства. И, как я уже говорил, для доступа клиента из тырьнета по RDP нужно применять дополнительные средства защиты. Если клиент авторизовался через VPN, то уже сразу ясно, «кому бить морду» и «за что»: за то, что забыл свой пароль (что, в принципе, простительно) или за попытку взлома чужого. Ну, либо за компроментацию (путём слива третьим лицам) ключей доступа.
The time has come it is quite clear, our antichrist isalmostalready here.
cообщаю, что таки-да, вкладка сия предназначена для соединение через сервис «Шлюз удаленных рабочих столов» (роли «Службы удаленных рабочих столов»), и при её использовании логи становятся значительно интереснее. Из «плюшек» фичи, что вполне очевидно из названия, — отпадение необходимости при большом парке RDP-машин пробрасывать для каждой отдельный порт на роутере: достаточно только 443 (фокус с «кривым» пробросом тоже работает) для сервера шлюза, дальнейшей коммутацией он занимается самостоятельно.
Из «заморочек» — обязательное внесение сертификата безопасности шлюза в хранилище доверенных центров сетификации клиента, что само по себе являясь нетривиальной для рядового клерка задачей, порождает так же и некоторые заморочки для админа, как то: сертификат должен быть сконфигурирован для того адреса по которому будет обращение клиентом, поэтому соответствие имени тестового сервера «win2008» (на который был сгенерён сертификат) IP-адресу, на тестовой удалённой клиентской машине мне пришлось добавлять в файл hosts. Во-вторых, я почему-то не нашёл ни в одном руководстве по конфигурированию шлюза упоминания о том, что группа «Администраторы» не подходит для разрешения в политике доступа к шлюзу (хотя по умолчанию добавляется именно она), и я вчера пол-вечера как дятел долбился в него и читал интернеты, пытаясь понять почему не работает. Так же, нигде не написано что при вводе пароля для шлюза нужно обязательно ставить галку «запомнить». Иначе меня не пускало ни при каких обстоятельствах. В общем, заморочек сильно больше, чем дохрена, и в случае если нет целого NAT-парка машин с RDP, нафик оно не нужно. Проще заюзать мной выше упомянутую банилку, и не париться.
The time has come it is quite clear, our antichrist isalmostalready here.
Мне очень понравилась новая возможность по работе с журналами событий в Windows 2008/7/Vista, называемая Event Log forwarding (subscription — или подписка), которая основана на технологии WinRM. Данная функция позволяет вам получить все события со всех журналов с множества серверов без использования сторонних продуктов и настраивается все это в течении всего пары минут. Возможно, именно эта технология позволит вам отказаться от столь любимых многими системными администраторами Kiwi Syslog Viewer и Splunk.
Итак схема такая, у нас есть сервер Windows 2008, запущенный в качестве коллектора логов с одного или нескольких источников. В качестве подготовительной работы нужно выполнить следующие 3 шага:
На коллекторе логов в командной строке с правами администратора запустите следующую команду, которая запустит службу Windows Event Collector Service, измените тип ее запуска в автоматический (Automatically — Delayed Start) и включите канал ForwardedEvents, если он был отключен. wecutilqc На каждом из источников нужно активировать WinRM: winrmquickconfig По умолчанию сервер-коллектор логов не может просто собирать информацию из журналов событий источников, вам придется добавить учетную запись компьютера-коллектора в локальные администраторы на все сервера-источники логов (в том случае, если сервер-источник работает под управлением 2008 R2, то достаточно добавить учетку коллектора в группу EventLogReaders)
Теперь мы должны создать подписки (Subscriptions) на сервер коллектор. Для чего зайдите на него, откройте консоль MMC Event Viewer, щелкните правой кнопкой мыши по Subscriptions и выберите Create Subscription:
Здесь вы можете выбрать несколько различных настроек.
При каждом добавлении коллектора, неплохо было бы проверить подключение:
Далее вы должны настроить фильтр, указав какие типы событий вы хотите получать (например, Errors и Warnings), также можно собирать события по конкретным номерам Event ID или по словам в описании события. Есть один нюанс: не выбирайте слишком много типов событий в одну подписку, анализировать этот журнал можно будет бесконечно :).
Расширенные настройки (Advanced settings) могут понадобиться, если вы хотите использовать нестандартный порт для WinRM, или захотите работать по протоколу HTTPS, или же оптимизировать сьор логов по медленным каналам WAN.
После нажатия OK подписка будет создана. Здесь вы можете щелкнуть правой кнопкой мыши по подписке и получить статус выполнения (Runtime Status), или перезапустить ее (Retry) если предыдущий запуск был неудачным. Обратите внимание, что даже если ваша подписка имеет зеленый значок, в процедуре сбора логов могут быть ошибки. Поэтому всегда проверяйте Runtime Status.
После начала работы подписки, вы сможете просматривать перенаправленные события. Имейте в виду, что если журналы очень большие, то их первичный сбор может занять некоторое время.
Конфигурацию можно посмотреть на вкладке Properties -> Subscriptions.
В том случае, если сбор логов не работает, сначала на сервере-источнике логов удостоверьтесь, что локальный файрвол настроен корректно и разрешает трафик WinRM.
Один раз, когда я добавил учетную запись сервера-коллектора в группу Event Log Readers, но не добавил ее локальные админы, была такая ошибка;
[WDS1.ad.local] – Error – Last retry time: 2010-09-28 16:46:22. Code (0×5): Windows Event Forward Plugin failed to read events. Next retry time: 2010-09-28 16:51:22.
Я попробовал добавить учетку сервера в группу локальных админов, в результате появилась такая ошибка:
[WDS1.ad.local] – Error – Last retry time: 2010-09-28 16:43:18. Code (0×7A): The data area passed to a system call is too small. Next retry time: 2010-09-28 16:48:18.
Оказывается, я выбрал в фильтре слишком много журналов для сбора. Поправив фильтры так, чтобы они собирали чуть меньше информации, я победил эту ошибку.
