Я использую BigFix в корпоративной среде и заметил, что недавний раунд исправлений Microsoft на 2016 год не прошел для небольшой группы ресурсов. Мне удалось обойти это, создав фикслеты Custom Copy Fixlets, используя измененную релевантность, однако релевантность, которую мне приходилось использовать, не всегда была согласованной, хотя большинство файлов находились в C:\Windows\Sytem32.
Например: MS16-031 - критерии, которые ищет моя платформа сканирования, основаны на номере версии для Ntdll.dll. Я создаю специальный фикслет с релевантностью:
((version of x64 file "C:\Windows\System32\Ntdll.dll") as string) < VersionNumberGoesHere
Это отлично сработало, так как я ранее создал анализ BigFix, ища Ntdll.dll используя релевантность:
if (exists x64 file "C:\Windows\System32\Ntdll.dll") then ((version of x64 file "C:\Windows\System32\Ntdll.dll") as string) else "Does Not Exist"
Мне удалось подтвердить, что актуальность для Custom Fixlet была почти с Анализом. По какой-то причине это не зеркальное отображение этих двух, но оно очень близко, и в списке Custom Fixlet есть все машины, отмеченные в результатах сканирования, так что я доволен.
Здесь возникает проблема: для некоторые файлы в C:\Windows\System32, Мне нужно использовать совершенно другой синтаксис, чтобы получить правильную информацию о номере версии, которую я ищу, на основе результатов сканирования. То есть я жестяная банка используйте метод, указанный выше, но информация о версии, которую он предоставит, даже не близка к той, которую ищет сканер. Если бы я использовал перечисленный выше метод, предполагая, что сканер ищет что-то вроде «Номер версии 6.1.7600.16385», результаты, которые я бы увидел, вместо этого были бы «1.1.11302.0». Это все равно будет какая-то очевидная нумерация версий, но совсем не похожая на тип, на который ссылается моя платформа сканирования.
Например: MS16-027 - чтобы найти информацию о версии файла для mfds.dll для анализа пришлось использовать:
value "FileVersion" of version block 1 of file "mfds.dll" of system folder
Для Custom Fixlet мне пришлось использовать:
value "FileVersion" of version block 1 of file "mfds.dll" of system folder != VersionNumberGoesHere (OSServicePatch_gdr.LongStringOfNumbers)
Я немного прочитал синтаксис Action Script для BigFix, и мне показалось, что x64 file (command) vs. file (command) может привести к разным результатам в зависимости от пути для 32-битных систем и 64-битных систем, однако я думал, что это применимо только к файлам, расположенным в C:\Program Files и C:\Program Files (x86)? Разве это не так? Если да, то где находится 64-битная версия System32 и почему результаты между ними так сильно различаются?
Чтобы уточнить, это вопрос актуальности BigFix, а не ActionScript BigFix.
Я скажу, что, хотя актуальность BigFix требует некоторого обучения и иногда затрудняет выявление источника сложности, проблемы, с которыми вы сталкиваетесь, больше связаны со сложностями того, как файлы могут иметь много разных типов версий. информацию плюс способ работы перенаправления WindowsOnWindows Microsoft.
Простая причина, по которой информация о версии файла может быть разной в зависимости от того, откуда вы ее читаете, заключается в том, что есть несколько мест для размещения версий файлов, и они могут точно совпадать, или они могут быть разными. Это зависит от создателя файла и того, как они хотят передать значение информации о версии.
Актуальность versions of files "mfds.dll" читает одно место, а релевантность values "FileVersion" of version blocks of files "mfds.dll" читает в другом месте.
Посмотреть здесь:
Q: (values "FileVersion" of version blocks of it, (it as string) of versions of it) of files "mfds.dll" of (system folders)
A: 10.0.14342.1000 (rs1_release.160506-1708), 10.0.14342.1000
T: 3.677 ms
I: plural ( string, string )
Я не думаю, что различия, которые вы видите, связаны с различиями между file и x64 file, но это важно понимать по многим причинам.
Для целей этого вопроса предположим, что мы говорим о 64-битном компьютере с Windows, и вы должны предположить, что это применимо к Windows Vista или более поздней версии, но также может относиться к 64-битной Windows XP.
Поскольку клиент BigFix - это 32-битный процесс, все операции чтения файлов, которые будут выполняться в специальные 64-битные местоположения, фактически перенаправляются Windows в 32-битное местоположение.
В чем разница между files и x64 files в актуальности BigFix? В случае большинства файлов использование либо files и x64 files фактически будет читать тот же файл. Это потому, что использование x64 files указывает BigFix читать файл с отключенным перенаправлением WindowsOnWindows (WoW), но это перенаправление применяется только к чтению по определенным путям. Одним из примеров является Program Files и другое существо System32, а что-то вроде C:\Windows\Temp вообще не затрагивается перенаправлением WoW, поэтому любой файл, читаемый в C:\Windows\Temp работает одинаково независимо.
C:\Program Files (x86)C:\Program FilesC:\Windows\SysWOW64C:\Windows\System32C:\Windows\sysnative Мы должны поблагодарить Microsoft за то, что в названии 64-битной системной локации указано 32, а в 32-битной системной локации - 64. Это определенно очень распространенный источник путаницы.
Используйте эту релевантность, чтобы увидеть, что на самом деле существует 2 копии mfds.dll в системе.
(name of it, size of it) of files "mfds.dll" of (system folders; system x64 folders)
Эта релевантность читает оба местоположения, потому что (system folders; system x64 folders) сообщает BigFix прочитать ОБЕИХ C:\Windows\SysWOW64 папка, а также C:\Windows\System32 папка.
Псих? Сбивает с толку? Подожди, становится еще страннее.
Запустите в отладчике фикслетов следующую релевантность: pathnames of files "mfds.dll" of (system folders; system x64 folders)
Q: pathnames of files "mfds.dll" of (system folders; system x64 folders)
A: C:\WINDOWS\system32\mfds.dll
A: C:\WINDOWS\system32\mfds.dll
T: 1.312 ms
I: plural string
Обратите внимание на то, что пути к обоим файлам совпадают, но это НЕ один и тот же файл !!!
Так работает перенаправление WindowsOnWindows. Он лежит на 32-битном процессе и сообщает ему, что он прочитал файл из C:\Windows\System32 место, даже если он прочитал это из C:\Windows\SysWOW64 вместо этого в случае использования system folders актуальность, значит, BigFix должным образом сообщает имя пути как C:\WINDOWS\system32\mfds.dll. Тогда в случае system x64 folders релевантности, BigFix (32-битный процесс) сообщает Windows, что хочет прочитать местоположение C:\Windows\System32 с отключенным перенаправлением, и в этом случае он фактически читает файл, расположенный в C:\WINDOWS\system32\mfds.dll и должным образом сообщает имя пути как таковое.
Я хотел бы повторить, это не имеет ничего общего с BigFix и все, что связано с реализацией Microsoft Windows 64bit с перенаправлением Windows 32bit.
Для будущих вопросов по BigFix я настоятельно рекомендую очень активные форумы: https://forum.bigfix.com/