Решал сегодня интересную задачу. В продукте ISA Server 2006 SP1 добавили функционал Change Tracking. Куда пишутся все изменения, которые происходят в ISA сервере. Вещь, достаточно удобная, но нет возможности настроить оповещение по электронной почте. Хотя было бы логичным, вот алерты же можно настроить. А изменения нельзя. По этой причине пришлось дописывать самому такой функционал.
Для начала изучил материалы по данному направлению, и был найдет скрипт с похожим функционалом. Но написан он был не на Powershell`е. Вот он. Из его материалов стало понятно, что данные хранятся в VPS (Vendor Parameter Set).
В итоге получил скрипт, который при изменениях отправляет почтовое извещение. Вот такого типа:
User
-----
INADMIN\bakanov
Time
-----
2010-12-19T17:35:10Z
Server
------
srvisa
Description:
------------
I`m Change settings for send email
Change Summary
--------------
Policy Rule [SendEmail] added
Change Extended
---------------
Policy Rule [SendEmail] [Name] is [SendEmail]
Policy Rule [SendEmail] [Order] is [8]
Policy Rule [SendEmail] [Action] is [fpcPolicyRuleActionAllow]
Policy Rule [SendEmail] From added reference to Network [Local Host]
Policy Rule [SendEmail] [ProtocolSelectionMethod] is [fpcSpecifiedProtocols]
Policy Rule [SendEmail] To added reference to Computer [SRV010]
Policy Rule [SendEmail] added reference to Protocol Definition [SMTP]
Policy Rule [SendEmail] added reference to User Set [All Users]
Краткое описание работы скрипта. В шапке – ничего интересного, просто задаем переменные. Интересным параметром является $RegPath, связанный с ISAChangeTrackingCount. Он описывает где в реестре будем хранить количество записей в БД VPS. От этого значения и будем отталкиваться. Просто так записи нельзя удалить, поэтому будем считать, что оно не меняется в сторону уменьшения. Поэтому этот случай я не рассматривал. А факт его увеличения говорит нам о том, что произошли какие-то изменения и их необходимо отправить на почту.
Во время первого запуска проверяется наличие нужных ключей в реестре, и если их нету, то считается, что запуск был первым и текущее количество записей Change Tracking будет первым. Оно запоминается в ISAChangeTrackingCount. Если же данная переменная содержит данные, то она сравнивается с текущим значением. Если в данный момент записей больше, то они отправляются на почту. Учтен тот вариант, что скрипт мог не запускаться какое-то время и в случае его удачного запуска на почту будет отправлено столько писем, сколько было изменений.
#Задаем где будем хранить инфу о последнем изменениние $RegPath = "HKLM:\Software\PS_Script\" #Почтовый сервер $IPMailServer="192.168.0.10" #От кого отправляем $SenderEmail="ISA@inadmin.ru" #Кому отправляем $RecipientEmail="test2@inadmin.ru" #========================================= #Функция отправки почты function Send-mail ($subj = "VM" ,$body = "Text") { $SMTPClient = new-object System.Net.Mail.SMTPClient $Msg = new-object System.Net.Mail.MailMessage $Msg.To.Add($RecipientEmail) $Msg.from=$SenderEmail $Msg.Subject = $subj $Msg.Body= $body $SMTPClient.Host=$IPMailServer $SMTPClient.Send($Msg) } #создаем объект, связывающий нас с СОМ объектом и подключаемся $root = new-object -comobject "FPC.Root" -Strict $arr = $root.Arrays.Connect("") #Получаем данные из VPS [xml]$XMLData = ($arr.VendorParametersSets.Item( "{1234C1BD-2502-4BDA-8EAD-B2DE4DD84A7D}" )).value("changes") #Проверяем существование в ресстре нужных ключей, если их нету, то добавляем данные о текущем #количестве изменений в ISA сервере if ((Test-Path -path $RegPath) -ne $True) { New-Item $RegPath Set-ItemProperty $RegPath ISAChangeTrackingCount $XMLData.changes.LogEntry.count } #Проверяем исть ли изменения с последнего запуска, на основе количеста записей if ((get-item $RegPath).getvalue("ISAChangeTrackingCount") -lt $XMLData.changes.LogEntry.count) { #Находим кол-во изменений в БД $ChangeCount = $XMLData.changes.LogEntry.count - (get-item $RegPath).getvalue("ISAChangeTrackingCount") #запускаем цикл для всех изменений for ( $LogEntryCount=0; $LogEntryCount -lt $ChangeCount ; $LogEntryCount++) { #задаем переменную, для сокращения длины. $ShortXML = $XMLData.changes.LogEntry[$LogEntryCount] #Задаем переменные, которым мы можем использовать в строке $TimeChange = $ShortXML.'Time-xs' $ChangeSummary = $($ShortXML.SummaryLine) | Select-Object @{Name ="Change Summary"; expression = {$_.Text}} | Out-string $ChangeExtended = $($ShortXML.DetailsLine) | Select-Object @{Name ="Change Extended"; expression = {$_.Text}} | Out-string #Данные, которые будем вкладывать в тело сообщения. $ChangeLog = " User ----- $($ShortXML.User) Time ----- $TimeChange Server ------ $($ShortXML.Array) Description: ------------ $($ShortXML.Desc) $ChangeSummary $ChangeExtended " #отправляем письмо Send-mail "ISA Notification" $ChangeLog } #Т.к. было изменение, то запишем в реесте новое значение кол-ва строк в БД изменений Set-ItemProperty $RegPath ISAChangeTrackingCount $XMLData.changes.LogEntry.count }
Хочется еще добавить, что данные в VPS добавляет сама оснастка MMC, которая была обновлена в SP1. К чему это приводит? К тому, что если вредитель получит доступ к серверу и исправит данные используя оснастку от простой ISA 2006 или напрямую, к примеру на ISA STD версии, через реестр. То обновления не будут записаны в VPS. И мы не узнаем об их изменениях. Конечно, это не самая удачная реализация. По этой причине можно запретить удаленное управлений через оснастку, и необходимо будет ходить через RDP на сервер с ISA сервером, где будет установлена оснастка от ISA SP1.
Подведу итог. Да это мониторинг в каком-то смысле, но не защита от изменения настроек. При сильной хотелке можно изменить параметры так, что бы они не отразились в VPS. Для полной защиты нужно парсить реестр на слежение изменений.


Интересный скрипт и странная задача.
Я бы добавил что разработчики могли бы реализовать не только оповещение по почте но и сохранение «откатного» варианта конфига на тот случай если администратор ошибся.
Вот по второму случаю очень за. А то всякое бывает….
Serg, а чем штатный «Export/Import» не устраивает.
По поводу отслеживания изменений конфигурации.
Надо также упомянуть, что решение Дениса предназначено для standalone-сервера, т.к. в журнал CT также не попадают изменения, считанные с сервера конфигурации.
Конфигурацию isa-сервер хранит в системном реестре (в случае с сервером конфигурации — кеш конфигурации), и очевидно, что отслеживать нужно не записи CT, а именно изменения объектов конфигурации, но проблема в том, что хранятся эти объекты в бинарном виде, а как их интерпретировать — документация (SDK) не раскрывает…
Ну по хорошему это решения не отслеживания изменений в конфигурации, а дополнение функционала к Change Tracking. Верно замечено, что работает только в одном конкретном случае. Хотя большАя часть установок ISA сервера такими и являются.
А для TMG этот скрипт не работает?
Нужно пробовать.
Ну в смысле у меня не заработало
TMG нет в продакшине, поэтому не было нужды переписывать. А вообще можно посмотреть вот сюда, в качестве примера: http://blogs.technet.com/b/isablog/archive/2008/07/21/change-tracking-configuration-via-script.aspx
Ну а дальше уже модифицировать под PoSh