Практический аудит логонов пользователей

Описание проблемы

Перед системным администратором периодически встают вопросы:

  • За каким компьютером работает пользователь, например, APetrov?
  • На какие компьютеры APetrov входил последнее время?
  • Кто недавно входил на компьютер BUHGALTERIA?

Настройка встроенного механизма аудита в Windows теоретически позволяет ответить на данные вопросы, но реальное конфигурирование аудита и, главное, последующий анализ журналов событий не столь удобны, как того хотелось бы.

Решение

Ниже приведен вариант решения проблемы аудита входов пользователей, который успешно применялся мной в большой корпоративной среде (более 2000 клиентов).

Решение основано на сценарии входа, который автоматически запускается при входе пользователя и обновляет файлы аудита в общей папке на файловом сервере.

Пошаговое руководство

Шаг 1. Создание скрытой общей папки

Для начала создаем папку на файловом сервере. Пусть папка будет называться \\Server1\log$. Значок $ на конце имени папки делает ее скрытой, т.е. при навигации по сетевому окружению пользователи такую папку не видят.

Устанавливаем группе Authenticated Users право Modify как на саму общую папку, так и на NTFS. Для проверки правильности конфигурации прав доступа желательно попробовать от имени пользователя создать в папке \\Server1\log$ какой-нибудь файл.

Шаг 2. Создание сценария для записи событий аудита

Создаем файл сценария с именем CurrentUser.vbs. Содержание файла вы найдете здесь или ниже в Приложении. Не забудьте изменить в файле путь к общей папке вместо \\Server1\log$.

Сценарий проверяет в указанной общей папке наличие двух файлов <UserName>.log и <ComputerName>.log. Если файлов нет, то они создаются. Затем в файл <UserName>.log добавляется имя компьютера и дата/время, а в файл <ComputerName>.log. добавляется имя пользователя и дата/время.

При желании в файлах можно сохранять дополнительные атрибуты пользователя, например, подразделение (если этот атрибут заполняется в Active Directory).

Шаг 3. Назначение сценария через групповую политику

Создаем групповую политику и добавляем в нее сценарий входа пользователя. Политику желательно привязать на уровень домена, чтобы она автоматически применялась ко всем пользователям.

Шаг 4. Проверка файла аудита

Тестируем. Для проверки достаточно залогиниться на любой компьютер и проверить факт создания новых файлов с именем пользователя и компьютера в скрытой папке. В дальнейшем все входы в систему будут фиксироваться в этих файлах.

Применение

Для ответа на вопросы “За каким компьютером работает пользователь,APetrov?” и “На какие компьютеры APetrov входил последнее время?” нужно всего лишь открыть файл \\Server1\log$\APetrov.log.

Для ответа на вопрос “Кто недавно входил на компьютер BUHGALTERIA?” нужно открыть файл \\Server1\log$\BUHGALTERIA.log.

Заключение

Описанное выше решение не гарантирует абсолютную достоверность данных, поскольку все пользователи потенциально могут отредактировать файлы аудита. При необходимости ведения “серьезного” аудита данное решение будет лишь дополнением к правильно настроенному аудиту Windows.

В реальной жизни решение оказалось очень удобным как для сотрудников службы Helpdesk, так и для администраторов сети.

При желании вы можете вносить свои модификации в файл сценария для сбора более детальной информации о пользователях или компьютерах.

 

Приложение

Листинг файла сценария CurrentUser.vbs

Не забудьте изменить в переменной strShareName путь к общей папке вместо моей папки \\Server1\log$.

Строку 'WScript.Sleep 60000 можно раскомментировать, если сценарий требуется запустить с задержкой выполнения.

Option Explicit
On error resume next

Dim objFSO, objNetwork, objShell, objTS, objADSystemInfo, objUser
Dim strUsername, strComputerName, strFileName, strShareName, strFile, strDepartment

strShareName = "\\Server1\log$"

'WScript.Sleep 60000 'delay listed milliseconds before script execution

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objNetwork = CreateObject("Wscript.Network")
Set objShell = CreateObject("Wscript.Shell")
Set objADSystemInfo = CreateObject("ADSystemInfo")
Set objUser = GetObject("LDAP://" & objADSystemInfo.UserName)

strUserName = objNetwork.UserName
strComputerName = objNetwork.ComputerName

strFileName = strUserName & ".log"
strFile = strShareName & "\" & strFileName

If objFSO.FileExists(strFile) Then
    'Do nothing
   else
    objFSO.CreateTextFile(strFile)
end if

Const FOR_WRITING = 2 'Replace all data within the file
Const FOR_APPENDING = 8 'Append data to the end of the file

Set objTS = objFSO.OpenTextFile(strFile,FOR_APPENDING)
objTS.Write "Date/time : " & Now & vbCRLF
objTS.Write "Computer  : " & strComputername & vbCRLF
objTS.Write vbCRLF
objTS.Close

strFileName = strComputerName & ".log"
strFile = strShareName & "\" & strFileName

If objFSO.FileExists(strFile) Then
    'Do nothing
   else
    objFSO.CreateTextFile(strFile)
end if

Set objTS = objFSO.OpenTextFile(strFile,FOR_APPENDING)
objTS.Write "Date/time : " & Now & vbCRLF
objTS.Write "User      : " & strUserName & vbCRLF
objTS.Write "Department: " & objUser.Department & vbCRLF
objTS.Write vbCRLF
objTS.Close

Wscript.Quit(1)

.

Пример файла аудита \\Server1\log$\APetrov.log

Date/time : 15.10.2010 09:39:54
Computer  : XP01

Date/time : 16.10.2010 09:40:13
Computer  : BUHGALTERIA

.

Пример файла аудита \\Server1\log$\BUHGALTERIA.log

Date/time : 16.10.2010 09:40:13
User      : APetrov
Department: IT

Date/time : 16.10.2010 09:50:52
User      : Maria Sidorova
Department: Accounting

.

Posted by Alexey Gorbunov on 10/29/2010 0 comments
Теги: , ,

Как работает домен .РФ

Теория

Особенностью функционирования системы DNS является поддержка ограниченного стандартами набора из 63 символов: буквы A…Z, a..z английского алфавита, цифры 0,,9 и знак дефиса. Обратите внимание, что символ подчеркивания разрешен только как специальный префикс для обозначений записей служб. Он используется, например, для регистрации в DNS различных служб Active Directory.

Для преодоления ограничения на количество используемых символов был придуман специальный обходной маневр в виде стандарта PUNYCODE. Смысл этого стандарта в том, что все неанглоязычные наименования доменов преобразуются в “нормальные” имена DNS, состоящие из 63 разрешенных символов. Чтобы отличать “неродные” записи от привычных нам для всех преобразованных названий вводится префикс xn--.

На данный момент в корневых DNS зарегистрированы два кириллических домена: .РФ и .ИСПЫТАНИЕ.

Практика

Доменная зона .РФ с точки зрения DNS является зоной xn--p1ai. А, например, доменное имя президент.рф трансформируется в красивое имя
xn--d1abbgf6aiiy.xn--p1ai.

Можно даже “попинговать” хост xn--d1abbgf6aiiy.xn--p1ai:

C:\>ping xn--d1abbgf6aiiy.xn—p1ai
Обмен пакетами с xn--d1abbgf6aiiy.xn--p1ai [195.208.24.91] с 32 байтами данных:
Ответ от 195.208.24.91: число байт=32 время=4мс TTL=57
Ответ от 195.208.24.91: число байт=32 время=5мс TTL=57
Ответ от 195.208.24.91: число байт=32 время=4мс TTL=57
Ответ от 195.208.24.91: число байт=32 время=4мс TTL=57

А вот команда ping президент.рф уже не работает, хотя сайт http://президент.рф открывается:

C:\>ping президент.рф
При проверке связи не удалось обнаружить узел президент.рф.
Проверьте имя узла и повторите попытку.

В чем же причина такой избирательности?

Причина кроется в том, что за преобразование всех “нестандартных” имен отвечают клиенты. И в приведенном выше примере современный браузер корректно трансформирует кириллическое имя сайта в его punycode-псевдоним, и уже этот псевдоним и запрашивается у серверов DNS. Команда ping про punycode-преобразования ничего не знает и запрашивает у DNS кириллическое имя, которое DNS найти, естественно, не может.

Если мы попробуем отправить письмо на адрес info@xn--d1abbgf6aiiy.xn--p1ai, то Outlook и многие онлайн-службы (Яндекс, Mail.ru), корректно обработают такой почтовый адрес. Outlook и Яндекс даже умеют отправлять письма на info@президент.рф. А Gmail, например, письма ни на punycode-домен, ни на кириллический пока не отправляет.

Если говорить о браузерах, то полноценная поддержка преобразований punycode встроена в IE7 и выше, Firefox 3.6.4 и выше.

Выводы

Punycode-преобразование – удел клиентского приложения.

Для работы многих ИТ-сервисов недостаточно только зарегистрированного в системе DNS кириллического имени. Необходимо убедиться, что все используемые в вашей организации и, возможно, в организациях-контрагентах клиентские приложения корректно преобразуют кириллические имена в стандартные для DNS запросы.

 

Похожие статьи: Настройка DNS для поддержки домена .РФ

 

Подробнее о списке корневых доменов: http://www.iana.org/domains/root/db/

Подробнее о стандарте RFC 1035 – DNS naming: http://tools.ietf.org/html/rfc1035

Подробнее о стандарте RFC 2782 – SRV records: http://tools.ietf.org/html/rfc2782 

Подробнее о стандарте RFC 3492 – Punycode: http://tools.ietf.org/html/rfc3492

Posted by Alexey Gorbunov on 10/28/2010 0 comments
Теги:

Резервное копирование сертификатов. Часть 4

Особенности резервного копирования сертификата и закрытого ключа при использовании смарт-карт

Каждая смарт-карта использует свое собственное хранилище для размещения сертификатов и закрытых ключей. Генерация пары асимметричных ключей (закрытого и открытого) производится внутри самой смарт-карты, и закрытый ключ затем никогда ее не покидает. Такой подход обеспечивает высокую степень защищенности закрытого ключа. Однако, выход из строя смарт-карты потребует полной замены цифровых сертификатов и последующей настройки приложений.

При необходимости создания резервной копии закрытого ключа и сертификата, хранимых на смарт-карте, необходимо сгенерировать запрос получения сертификата вне смарт-карты, сохранить полученный сертификат в формате .pfx, а затем импортировать сертификат и закрытый ключ в смарт-карту.

Файл в формате .pfx и будет требуемой резервной копией, которую затем можно будет восстановить на другой смарт-карте.

P.S. Для возможности экспорта закрытого ключа из локального хранилища не забудьте заранее разрешить экспорт закрытых ключей в свойствах шаблона запрашиваемого сертификата и затем указать в запросе на получение сертификата, что ключ является экспортируемым. При экспорте сертификата в файл .pfx лучше указывать опцию удаления из компьютера локальной копии закрытого ключа, чтобы затем закрытый ключ физически сохранялся только в резервном файле и на самой смарт-карте.

 

Подробнее о смарт-картах и Windows PKI:
http://technet.microsoft.com/en-us/library/dd277377.aspx

Схема процесса генерации ключей для смарт-карт:
http://technet.microsoft.com/en-us/library/Dd277377.smar0307_big(en-us,TechNet.10).gif

Подробнее о процедуре запроса сертификата для смарт-карты:
http://technet.microsoft.com/en-us/library/dd277383.aspx

Подробнее об импорте ключей в смарт-карту:
http://blogs.technet.com/b/pki/archive/2007/11/13/manually-importing-keys-into-a-smart-card.aspx

 

Связанные статьи:

Posted by Alexey Gorbunov on 10/27/2010 0 comments
Теги:

Резервное копирование сертификатов. Часть 3

Централизованное резервное копирование сертификатов и закрытых ключей средствами Службы Сертификатов Microsoft

Централизованное резервное копирование цифровых сертификатов устраняет ряд сложностей, которые возникают при ручном архивировании сертификатов:

  • упрощается администрирование централизованного хранилища сертификатов и закрытых ключей;
  • отпадает необходимость обхода всех клиентских машин;
  • появляется возможность полной автоматизации процесса архивации;
  • восстановление отдельных сертификатов можно делегировать выделенному агенту или агентам.

Суть централизованного автоматического архивирования сертификатов сводится к архивированию базы Службы Сертификатов.

Но! По умолчанию база Службы Сертификатов содержит в себе только сами сертификаты, а закрытые ключи всегда генерируются на локальных компьютерах и затем никуда из локального хранилища не передаются.

Как же заставить локальные компьютеры передавать центру сертификатов свой закрытый ключ?

Ответ следующий. До начала генерации запросов на получение клиентских сертификатов системный администратор должен выполнить следующие действия:

  • настроить Key Recovery Agent (KRA) на сервере сертификатов. KRA может быть несколько;
  • настроить в свойствах шаблона сертификатов разрешение на архивацию закрытого ключа.

После выполнения этих действий клиентский компьютер в процессе получения клиентского сертификата будет автоматически передавать на сервер сертификации свой закрытый ключ, а центр сертификации, в свою очередь, будет сохранять этот ключ в базе сертификатов в зашифрованном виде (с помощью ключа KRA) как дополнительный атрибут сертификата.

Восстановление сертификата вместе с закрытым ключом выполняется с помощью сертификата и закрытого ключа KRA в стандартный файл .pfx, который затем импортируется на клиентском компьютере.

Планирование безопасного хранения и применения закрытого ключа KRA является критически важным элементом политики безопасности цифровых сертификатов. Закрытый ключ KRA, фактически, становится мастер-ключом, позволяющим дешифровать любые закрытые ключи, сохраненные в базе Службы Сертификатов.

При планировании политики централизованного архивирования ключей необходимо учитывать и некоторые ограничения. Некоторые из них перечислены ниже:

  • шаблоны клиентских сертификатов должны быть версии 2 или 3 (версия 3 нужна для использования шифрации CNG);
  • для генерации асимметричных ключей должен использоваться алгоритм RSA; ключи, сгенерированные другими алгоритмами, не архивируются средствами Службы Сертификатов.

Пошаговое руководство по централизованному архивированию ключей есть в учебном курсе 6426 “Конфигурирование и устранение неисправностей решений идентификации и управления доступом на основе Windows Server 2008 Active Directory".

 

Подробнее о процедуре архивации закрытых ключей для серверов Windows Server 2003: http://technet.microsoft.com/ru-ru/library/cc738977(WS.10).aspx

Подробнее о процедуре архивации закрытых ключей для серверов Windows Server 2008: http://technet.microsoft.com/en-us/library/ee449489(WS.10).aspx

Подробнее о резервном копировании базы Службы сертификатов в Windows Server 2008: http://blogs.technet.com/b/pki/archive/2010/08/06/backing-up-windows-server-2008-adcs-ca-keys.aspx

 

Связанные статьи:

Posted by Alexey Gorbunov on 10/27/2010 0 comments
Теги:

Резервное копирование сертификатов. Часть 2

Архивирование клиентских сертификатов и ключей вручную

Архивирование сертификатов при данном подходе выполняется методом экспорта сертификата в файл.

Экспорт цифрового сертификата может быть выполнен в одном из двух форматов:

  • экспорт только сертификата без экспорта закрытого ключа;
  • экспорт сертификата вместе с закрытым ключом.

 

Для выполнения операции экспорта пользовательского сертификата необходимо подключиться к пользовательскому хранилищу сертификатов.

Первый способ – открыть Microsoft Management Console и добавить в нее оснастку Сертификаты.

Второй, более простой способ добраться до цифровых сертификатов пользователя, – открыть Internet Explorer и в свойствах обозревателя открыть вкладку Содержание.

clip_image001

При нажатии кнопки Сертификаты открывается окно, выводящее несколько вкладок различных типов сертификатов, которые есть у пользователя. В нашем случае нужна первая вкладка Личные.

Выбрав нужный сертификат, нажимаем кнопку Экспорт… и в запустившемся мастере экспорта выбираем формат экспортируемого файла.

clip_image002

На приведенном выше рисунке первые три опции доступны, а вот четвертая опция Файл обмена личной информацией – PKSC #12 (.PFX) является недоступной. Почему?

Потому что первые три опции экспортируют в файл только сам сертификат, а закрытый ключ остается в операционной системе. Четвертая же опция экспортирует сертификат вместе с закрытым ключом и данная операция является критичной с точки зрения безопасности. Для того, чтобы вы могли экспортировать из системы закрытый ключ, ваш запрос на получение сертификата должен заранее содержать разрешение на экспорт ключа, а шаблон сертификата (это уже настройки самого центра сертификации) должен разрешать такие запросы.

 

Ваши задачи как системного администратора в данном случае - заранее спланировать возможность экспорта закрытых ключей из клиентской машины (опция Allow private key to be exported на вкладке Request Handling в свойствах шаблона сертификата), а затем обойти все клиентские машины и экспортировать в централизованное хранилище (флешка, общая папка) клиентские сертификаты в формате .pfx.

Организационные и технические вопросы защиты централизованного хранилища фалов .pfx выходят за рамки данной статьи.

Процесс восстановления сертификатов в нашей схеме будет очень простой: после переустановки операционной системы и приложений нужно дважды щелкнуть на сохраненном файле .pfx и импортировать сертификат и закрытый ключ в хранилище.

 

Подробнее о настройках шаблонов сертификатов: http://technet.microsoft.com/en-us/library/cc725621(WS.10).aspx.

 

Связанные статьи:

Posted by Alexey Gorbunov on 10/27/2010 0 comments
Теги:

Резервное копирование сертификатов. Часть 1

Общая часть

Клиентские цифровые сертификаты широко используются в современных коммуникациях. Варианты их применения могут быть самые различные:

  • клиентские сертификаты для подключения к веб-серверу по SSL (например, в системах клиент-банк);
  • клиентские сертификаты для шифрования данных (например, при использовании Encrypted File System – EFS);
  • клиентские сертификаты для добавления цифровой подписи в сообщения электронной почты.

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

На клиентском компьютере с  Windows XP пользовательские сертификаты хранятся в открытом виде в профиле пользователя в папке \Application Data\Microsoft\SystemCertificates\My\Certificates. После входа пользователя в систему сертификаты записываются в специальную область в реестре, откуда к ним получают доступ приложения. Ассоциированные с сертификатами закрытые ключи хранятся в зашифрованном виде в профиле пользователя в папке \Application Data\Microsoft\Crypto\RSA. Закрытые ключи зашифрованы с помощью периодически обновляемого мастер-ключа пользователя.

Что произойдет с приложениями, если клиентский сертификат или закрытый ключ окажутся недоступными, например, при полной переустановке операционной системы или полном удалении профиля пользователя? Ответ очевиден, функционировать приложения не смогут, расшифровать данные будет невозможно.

Для предотвращения описанной выше ситуации системному администратору необходимо спланировать процедуры резервного копирования сертификатов и закрытых ключей.

Возможные варианты резервного копирования сертификатов следующие:

  • экспорт сертификатов и ключей вручную в отдельные файлы;
  • централизованное архивирование сертификатов и ключей средствами Certificate Services (AD CS в Windows Server 2008).

В последующих статьях я рассмотрел варианты резервного копирования подробнее:

Чтобы не перегружать статьи я постарался сконцентрироваться на описании самого процесса архивирования ключей, а не детальных шагах и скриншотах. Если информации окажется недостаточно, оставьте свой комментарий, я с удовольствием добавлю нужные детали.

Posted by Alexey Gorbunov on 10/27/2010 0 comments
Теги:

Создание белых и черных списков доменов в ISA Server 2006

При обслуживании серверов ISA Server часто возникает вопрос автоматизации импорта белых или черных списков сайтов, которые используются для настроек правил доступа.

Однажды я решил эту задачу и предлагаю вам свой вариант решения.

На сервере требуется создать в папку C:\Lists и разместить в ней следующие файлы:

  • BLACK_List_Domains.txt (текстовый файл, содержит черный список доменов)
  • WHITE_List_Domains.txt (текстовый файл, содержит белый список доменов)
  • UpdateNameSet.vbs (сценарий обновления наборов доменных имен)
  • SortTextFile.vbs (сценарий для сортировки списков в текстовых файлах)
  • _Update.bat (пакетный файл обновления наборов доменных имен)

Для обновления наборов доменов требуется внести изменения в соответствующий текстовый файл, а затем запустить файл _Update.bat.

Сценарий автоматически добавляет домен и все нижележащие домены в набор. Например, для домена xxx.ru сценарий внесет в набор записи xxx.ru и *.xxx.ru.

Важно! Доступ к отдельным страницам сайтов должен регулироваться через наборы URL, а не через наборы доменных имен.

Примечание. Не забудьте настроить политики ISA Server, чтобы белый список имел более высокий приоритет, чем черный. Например, если домен rbc.ru находится и в черном, и в белом списке, то доступ к сайту http://rbc.ru был бы разрешен.

 

Download: Lists.zip
Posted by Alexey Gorbunov on 10/25/2010 0 comments
Теги: , , ,
Подписаться на: Сообщения (Atom)