Решал сегодня интересную задачу. В продукте 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. Для полной защиты нужно парсить реестр на слежение изменений.

, ,


8 комментариев

  1. Интересный скрипт и странная задача.

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

  2. Баканов Денис @ 2010-12-20 09:19

    Вот по второму случаю очень за. А то всякое бывает….

  3. Дмитрий Пономарев @ 2011-01-27 14:44

    Serg, а чем штатный «Export/Import» не устраивает.

    По поводу отслеживания изменений конфигурации.
    Надо также упомянуть, что решение Дениса предназначено для standalone-сервера, т.к. в журнал CT также не попадают изменения, считанные с сервера конфигурации.
    Конфигурацию isa-сервер хранит в системном реестре (в случае с сервером конфигурации — кеш конфигурации), и очевидно, что отслеживать нужно не записи CT, а именно изменения объектов конфигурации, но проблема в том, что хранятся эти объекты в бинарном виде, а как их интерпретировать — документация (SDK) не раскрывает…

  4. Баканов Денис @ 2011-01-27 22:47

    Ну по хорошему это решения не отслеживания изменений в конфигурации, а дополнение функционала к Change Tracking. Верно замечено, что работает только в одном конкретном случае. Хотя большАя часть установок ISA сервера такими и являются.

  5. А для TMG этот скрипт не работает?

  6. Баканов Денис @ 2011-03-19 12:30

    Нужно пробовать.

  7. Ну в смысле у меня не заработало :)

  8. Баканов Денис @ 2011-03-23 00:43

    TMG нет в продакшине, поэтому не было нужды переписывать. А вообще можно посмотреть вот сюда, в качестве примера: http://blogs.technet.com/b/isablog/archive/2008/07/21/change-tracking-configuration-via-script.aspx

    Ну а дальше уже модифицировать под PoSh

Добавить новый комментарий