Kido #3 - Исцеление

Собственно, как с этой заразой бороться в случае заражения сети. Исходные данные следующие:

- Доменная сеть, серверы на Windows 2003, клиенты на XP x86 SP2 или SP3 (rus, eng).
- Антивирус есть, обновленный, но активную заразу не выкорчевывающий, хотя новую заразу отстреливает исправно.
- Активная зараза есть, пытается пробиться на другие машины.
- Серверы вычищены.
- Клиентов много, речи о том, чтобы лечить каждого руками не идет в силу их географической разбросанности.
- Вариант административного заражения сети исключен.

На помощь приходят две политики. Первая - расстановка всех нужных обновлений. Как уже было написано, их три: MS08-067, MS08-068, MS09-001. Тащим с сайта MS версии этих заплаток для всех языков, которые используются. В нашем случае их два - русский и английский. Все скачанное складываем в отдельную сетевую папку. В итоге получаем нечто вроде этого:
Каталог \хр.
Подкаталог \ms08-067. Файлы WindowsXP-KB958644-x86-ENU.exe и WindowsXP-KB958644-x86-RUS.exe
Подкаталог \ms08-068. Файлы WindowsXP-KB957097-x86-ENU.exe и WindowsXP-KB957097-x86-RUS.exe
Подкаталог \ms09-001. Файлы WindowsXP-KB958687-x86-ENU.exe и WindowsXP-KB958687-x86-RUS.exe

Материал для расстановки подготовлен. Теперь пишем сценарий установки:

Update.vbs

'Set WshShell
Set WshShell = CreateObject("Wscript.Shell")

'Disable Security Warning for Network Files
set oEnv = WshShell.Environment("PROCESS")
oEnv("SEE_MASK_NOZONECHECKS") = 1

'Define OS Language
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colOperatingSystems = objWMIService.ExecQuery _
("Select * from Win32_OperatingSystem")
For Each objOperatingSystem in colOperatingSystems
If objOperatingSystem.OSLanguage = "1033" then strLang = "ENU"
If objOperatingSystem.OSLanguage = "1049" then strLang = "RUS"
Next

'Run MS08-067 Patch
Description = ""
Description = WshShell.RegRead("HKLM\SOFTWARE\Microsoft\Updates\Windows XP\SP4\KB958644\Description")
If Description = "" Then
strCommand = "xp\ms08-067\WindowsXP-KB958644-x86-" & strLang & ".exe /passive /norestart"
WshShell.Run strCommand,,true
Restart = 1
End if

'Run MS08-068 Patch
Description = ""
Description = WshShell.RegRead("HKLM\SOFTWARE\Microsoft\Updates\Windows XP\SP4\KB957097\Description")
If Description = "" Then
strCommand = "xp\ms08-068\WindowsXP-KB957097-x86-" & strLang & ".exe /passive /norestart"
WshShell.Run strCommand,,true
Restart = 1
End If

'Run MS09-001 Patch
Description = ""
Description = WshShell.RegRead("HKLM\SOFTWARE\Microsoft\Updates\Windows XP\SP4\KB958687\Description")
If Description = "" Then
strCommand = "xp\ms09-001\WindowsXP-KB958687-x86-" & strLang & ".exe /passive /norestart"
WshShell.Run strCommand,,true
Restart = 1
End If

'Start AU Service
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colServiceList = objWMIService.ExecQuery _
("Select * from Win32_Service where Name='wuauserv'")
For each objService in colServiceList
errReturn = objService.StartService()
Next

'Start BITS Service
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colServiceList = objWMIService.ExecQuery _
("Select * from Win32_Service where Name='bits'")
For each objService in colServiceList
errReturn = objService.StartService()
Next

'Start Error Report Service
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colServiceList = objWMIService.ExecQuery _
("Select * from Win32_Service where Name='ersvc'")
For each objService in colServiceList
errReturn = objService.StartService()
Next

'Final Warning
If Restart = 1 then
Wscript.echo "На ваш компьютер были установлены обновления безопасности операционной системы. Рекомендуется как можно быстрее перезагрузить компьютер для их применения."
End If

'Enable Security Warning for Network Files
oEnv.Remove("SEE_MASK_NOZONECHECKS")


Вот так он выглядит. Сам файл сценария надо будет положить в каталог xp. После чего создается новый объект групповой политики, который привязывается к группе Domain Computers, а группа серверов исключается из области действия. В этой политике нужно будет задать в Параметрах компьютера сценарий загрузки. Сам сценарий представлен выше.
Что он делает. По-очереди проверяет наличие каждой заплатки в системе. Если не находит какую-то - устанавливает. После установки обновок выполняется принудительный запуск служб Автоматического обновления, Фоновой интеллектуальной передачи данных, и службы отправки сообщений об ошибках. Эти три службы блокируются заразой во время ее действия.

Обновления установлены. Следующий шаг - вынести заразу из памяти компьютера, если она там есть, и из места ее хранения - system32. Попутно вынести ключи реестра, которые ее запускают. В этом помогает, как уже тоже было написано, утилита от Касперского - Kkiller версии 3.4.1. Но с ней есть одна тонкость. Она категорически отказывалась работать вне пользовательского окружения. Иными словами - корректно у меня она срабатывала только тогда, когда пользователь уже зашел в систему. Здесь засада - для манипуляций с каталогом system32 нужны административные права, а у пользователя их нет и быть не должно. Получается, что запускаться Kkiller должен от имени администратора, а как такое можно обеспечить в момент захода обычного пользователя? Простое добавление в автозагрузку не поможет, назначение обычного сценария загрузки - аналогично, потому что все эти средства запускают приложения от имени того пользователя, что сейчас выполняет вход в систему. Казалось бы, ситуация не самая хорошая. Спасибо коллеге из Москвы, поведал он мне про утилиту lsrunase.exe, которая, будучи запущенной с определенным набором параметров, позволяет запустить какое-либо приложение от имени другого пользователя. Благодаря ей задача сводится к достаточно простой групповой политике, в которой будут участвовать следующие компоненты: сценарий входа в систему для пользователя, утилита lsrunase, файл kkiller.exe. Все три компонента нужно будет положить в сетевую папку, подобно обновлениям, описанным выше. Сценарий входа пользователя будет выглядеть примерно так:

RunKiller.bat

\\%NETWORK-SHARE%\lsrunase /user:%USER-NAME% /password:%ENCRYPTED-USER-PASS% /domain:%USER-DOMAIN% /command:"\\%NETWORK-SHARE%\kkiller.exe -f

Как видно, сценарий прост до безобразия. Однако, есть один момент, кроется он в шифровании пароля пользователя - Encrypted-user-pass. Как зашифровать пароль? Ответ прост. Вместе с утилитой lsrunase распространяется и утилитка LSEncrypt.exe. Она-то и позволяет зашифровать любую текстовую информацию. Шифрованную же строку можно будет использовать в сценарии.
Мой подход базируется на следующем. Сценарий входа будет выполняться при каждом входе каждого пользователя, к которым будет применена политика. Что называется - параноидальный режим, а иначе нельзя. Само собой, что во время сканирования утилитка будет кушать какую-то часть ресурсов компьютера, но с этим придется мириться.
Должен сказать еще пару слов о самой lsrunase. Эта утилита является платной. Поэтому ссылок на ее загрузку здесь дано не будет. В качестве light-версии оной распространяется программа lsrunas - делает абсолютно то же самое, но с одним ограничением - она пароль не шифрует. Это значит, что в сценарии он будет прописан в открытом виде, равно как в таком же виде будет передан по сети. Если есть уверенность в том, что шифрование не столь важно - можно использовать ее: Страница разработчика.
После того, как сценарий подготовлен, прописываем его в групповой политике как сценарий входа пользователя. А затем остается только ждать, когда будет перезапущен компьютер. После этого произойдет установка необходимых заплаток, что исключит возможность повторного использования уязвимости, а затем, когда в систему войдет пользователь, запустится утилита Kkiller, которая уничтожит зловреда в памяти и основных местах его "обитания". После этого уже можно будет дать команду основному антивирусному средству на полное сканирование системы для очистки от всей остальной заразы.

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

@музыка: Guano Apes - No Speech

@темы: Viruses and Spam, Security

---

Kido #2 - Противодействие

Лечение сети. Как уже ранее было написано, первое - это серверы. Их еще три. Впрочем, это уже намного меньше, чем в начале вакханалии. Основная проблема кроется даже не в самой процедуре лечения, не в том, что нужно еще найти, как убивать вредоноса. Нет, проблема в пользователях. Самое парадоксальное - их и винить не в чем, в конце концов, тот факт, что блокировка учетных записей идет почти непрерывно - всецело "заслуга" IT отдела. Поэтому приходится из двух зол выбирать то, что меньше буянит - то есть отключение блокировки учеток. Данная мера снижает безопасность сети в целом, но о какой безопасности может идти речь в такой ситуации. Пароли административных записей сменены, нужно обеспечить работу предприятия в целом.
Итак - как это сделать. Снова уже до боли знакомые нам групповые политики.
Создать новую, прицепить ее к корню домена. Областью действия назначить Authentificated users (в русской версии - Прошедшие проверку). Далее настройка самой политики:
Computer Configuration - Windows Settings - Security Settings - Account Policies - Account Lockout Policies.
Параметр Account Lockout Threshold выставить в 0. Два оставшихся держим как Not Applicable (Не задано)
После чего - ждем полтора часа. Это время, в течение которого политика применяется к клиентским компьютерам. В течение этого промежутка времени блокировки еще будут проходить.

С блокировками более мене понятно, после этих мер по крайней мере не будут отвлекать от работы. Остается другая проблема - безумная активность сети. Небольшой факт - за пару минут червь способен заблокировать более 70 учетных записей при минимальном количестве включенных компьютеров (относительно дневного времени, конечно). Соответственно, проблема в медленной работе сети в целом. Можете себе представить, каково приходится контроллерам домена, которые вынуждены обрабатывать лавину запросов. Нужно это как-то остановить. Если сеть большая, и поражена немалая ее часть - спасает только массовая проверка в режиме максимальной злобности. Если же есть уверенность, что точек заражения немного, то можно очень быстро их локализовать. В этом нам помогут политики контроллеров домена.
Работа в домене имеет одну особенность - практически любая активность пользователя порождает событие, которое контроллер может зафиксировать у себя в журнале. В случае борьбы с Kido - незаменимый инструмент. Критерием отбора пораженных машин будет постоянный поток сообщений о непройденной регистрации в домене. Нужно лишь включить регистрацию подобных событий. Как сделать:
Новая политика контроллеров домена - Computer Configuration - Windows Settings - Security Settings - Local Policies - Audit Policy
Включить параметр Audit Account Logon Events, Failure
Включить параметр Audit Logon Events, Failure
Применить политику к контроллерам домена, после чего ждать 5 минут. В течение этого времени политика применяется ко всем контроллерам.
После того, как политика будет применена, нужные нам сведения можно будет отыскать в Журнале Событий контроллера домена в журнале Безопасности. Там все будет достаточно прозрачным.

Ну и последнее на сегодня. Между моментом создания политики отмены блокировки учетных записей и моментом ее применения проходит весьма значительный промежуток времени, за который в домене могут снова появиться заблокированные пользователи. Как от таких избавиться? Искать их руками занятие бессмысленное. Гораздо проще воспользоваться скриптом, которых находит в домене все заблокированные учетные записи и сбрасывает с них флаг блокировки. Сам сценарий выглядит вот так:

Unblock Users in Domain.vbs

Unblock Users in Domain.vbs

' Constants for the NameTranslate object.
Const ADS_NAME_INITTYPE_GC = 3
Const ADS_NAME_TYPE_NT4 = 3
Const ADS_NAME_TYPE_1779 = 1

' Determine DNS domain name.
Set objRootDSE = GetObject("LDAP://RootDSE")
strDNSDomain = objRootDSE.Get("defaultNamingContext")

' Use the NameTranslate object to convert the DNS domain name
' to the NetBIOS domain name.
Set objTrans = CreateObject("NameTranslate")
objTrans.Init ADS_NAME_INITTYPE_GC, ""
objTrans.Set ADS_NAME_TYPE_1779, strDNSDomain
strNetBIOSDomain = objTrans.Get(ADS_NAME_TYPE_NT4)
' Remove trailing backslash.
strNetBIOSDomain = Left(strNetBIOSDomain, Len(strNetBIOSDomain) - 1)

' Find locked out user accounts in domain
' create array of sAMAccountName's
Set objDomain = GetObject("WinNT://" & strNetBIOSDomain)
objDomain.Filter = Array("user")
k = 0
For Each objWinNTUser In objDomain
If (objWinNTUser.IsAccountLocked = True) Then
objWinNTUser.IsAccountLocked = False
objWinNTUser.SetInfo
k = k + 1
End If
Next

If (k = 0) Then
Wscript.Echo "No user accounts locked out in domain"
Wscript.Quit
Else
Wscript.echo "All locked out users are unlocked (" & k & " accounts)"
wscript.quit
End If

Копирайт не мой.

Я искренне надеюсь, что никому его не придется применять. Борьба с Kido - вещь все же выматывающая.

@музыка: Madonna - Rain

@темы: Viruses and Spam, Security

---

Kido - Знакомство

Kido. Donwadup. Conficker.
Я его называю по первому имени, потому как впервые вредонос мне попался именно под ним. Все вышеперечисленное - это он же, у разных антивирусных программ он определяется по-разному.
В последние несколько месяцев этот червь стал настоящим бичом интернета и компьютерных сетей вообще. Сейчас я постараюсь сжато описать все то, что мне про него известно, впрочем, более развернутую информацию в Сети найти труда не составляет.
Итак, червь. Представляет из себя DLL файл, размеры от 150 до 160 кб. Векторы атаки:
1. Главное - использование уязвимости в службе Server компьютера. Успешное использование которой дает зловреду возможность окопаться в системе абсолютно прозрачно для пользователя. Подробность - злоумышленник получает доступ к ресурсу $ADMIN компьютера, который ведет прямиком в каталог Windows\system32. Именно там червь и старается положить копию самого себя. После этого создается запись в реестре, которая определяет на компьютере новую службу с именем, состоящим из произвольного набора символов. Это обеспечивает автоматический запуск червя при старте системы.
Обеспечение запуска - использование "Планировщика задач". Создаются задачи с именами atxxx, где ххх - порядковый номер задачи. Отсчет идет с нуля. Задачи повторяются каждый час, именно они запускают червяка в системе.
2. Использование флешек и сетевых дисков. Задействован механим автоматического воспроизведения (Autorun). В случае успешного исполнения - см. пункт 1 в части каталога System32 и далее.

Признаки заражения.
Первое и главное - невозможность выйти на сайт практически ни одного производителя антивирусного ПО. Microsoft в том числе. Если на компьютере "вчера все работало, а сегодня - нет" - можно "поздравить" - заражение прошло. Требуется еще уточнить момент, идет ли работа в интернет через прокси. Если нет, заражение стопроцентно. Если да - то возможно заражен и прокси-сервер. Именно с такой ситуацией довелось столкнуться мне.
Второе. Червь во время работы блокирует запуск служб Windows: Automatic Updates, Background Intellegent Transfer Service (BITS).
Третье (справедливо для доменых сетей). происходят практически постоянные блокировки пользовательских учетных записей и-за того, что червь все время пытается подобрать их пароли для дальнейшего распространения. Это также приводит к замедлению работы сети в целом из-за многократно возросших объемов передачи данных.
Четвертое. Наличие новых задач в планировщике. Как указано выше - задачи с именами atxxx - следствие атаки на компьютер.

Как бороться с активным заражением.
Если есть возможность - отключить зараженную систему от сети.
В первую очередь, необходимо нейтрализовать червя, если он уже находится в памяти. В этом может помочь утилита от Лаборатории Касперского - Клац!. По ссылке находится также инструкция по ее применению. Подобные утилиты появились и у других вендоров. Утилита Касперского уничтожает вредоноса в памяти, вычищает из реестра информацию о службе, которую червь прописывает в систему, удаляет вирусное тело из каталога System32, а также еще нескольких каталогов, где червяк может содержать свои резервные копии.
После нейтрализации червя следует как можно быстрее установить на компьютер исправления, описанные в бюллютенях безопасности MS08-067, MS08-68, MS09-001. Без этого ни одна мера противодействия не будет эффективной. Установка данных обновлений закроет основной канал доставки вредоноса. После патча системы нужно включить службы автоматического обновления и фоновой интеллектуальной передачи данных (BITS), если они отключены.
Следующий шаг - предотвращение повторного заражения. Отключаем автоматическое восстановление системы, полностью обновляем текущее антивирусное ПО, базы должны быть самыми свежими. Проводим полное сканирование системы. Все найденное и имеющее отношение к вредоносу удаляем сразу и без вопросов. Примечательно, что Касперский может вылечить DLL-файл от вируса. Лечить там нечего.

Проактивная защита или предотвращение заражения
Нужно отключить неиспользуемые службы операционной системы. Так, если у вас нет сети, в которой вы делаете какие-то свои данные доступными для всех - можно остановить службу "Server", которая как раз и ведает общими ресурсами: файлами, папками, принтерами (а именно она и является основным каналом заражения). Однако необходимо помнить, что если появится необходимость использования общих файлов и папок, службу придется снова включить. И также нужно помнить, что список таких ненужных служб всецело определяется задачами, решаемыми на компьютере.
Следующее - отключение автоматического воспроизведения. Об этом мне уже доводилось писать.
Еще одна мера - блокировка реестра. Предупреждение: выполнять эту процедуру следует только людям, имеющим опыт работы с реестром системы и способным восстановить его в случае некорректной работы.
Червь внедряется в пространство сетевой службы Svchost, делая запись об этом в следующем ключе реестра

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost

в параметре netsvcs. Если раскрыть этот параметр и прокрутить список вниз, при заражении там будет стоять запись о новой службе с именем, состоящим из произвольного набора букв. Следовательно, можно не дать червю прописаться в системе, заблокировав для изменения приведенный выше раздел реестра. Для этого нужно нажать на его имени правой кнокой, выбрать пункт разрешения и в появившемся окошке убрать флаг полного доступа для Администраторов компьютера и Системы, оставив режим чтения. Само собой, делать это нужно, если заражения в системе нет.

Особо - заражение сети.
В особо плачевных случаях заражение сети будет идти от административной учетной записи домена. Практически это самый паскудный сценарий, так как даже установка патчей от Microsoft не будет играть никакой роли, заражение будет происходить не при помощи уязвимости, а при помощи вполне легальных (с точки зрения домена) действий администратора. В первую очередь придется либо блокировать скомпрометированную учетку, либо менять ее пароль; и только потом проводить лечение сети. Начинать нужно будет с серверов, первыми среди них должны идти контроллеры домена, затем файловые серверы, затем прокси-сервер (последнее нужно для корректной работы антивирусных программ). На практике в подобных случаях меняются пароли всех административных учетных записей.

И главное.
Правило номер один. Windows - весьма сложная система, поэтому ошибки в ее работе были, есть, и скорее всего будут. Именно поэтому важно вовремя ее обновлять, устраняя неисправности и уязвимости. Механизм автоматического обновления как раз помогает в этом.
Правило номер два. Не пренебрегайте антивирусной защитой. Даже устаревающий сейчас сигнатурный метод обнаружения все еще не стоит сбрасывать со счетов.
Правило номер три, которое большей частью народа (каюсь, мной тоже) начисто игнорируется. Пользователь с административными правами не предназначен для постоянной работы в системе. Заведите себе учетную запись обычного пользователя и работайте под ней, это убережет вас от многих напастей. Не всех (Kido тому пример), но многих.

@музыка: Gamma Ray - Send me a sign

@темы: Viruses and Spam, Security

---

Files and Space

Можно сказать, экзамен выдержал. Очередная проблема с Exchange, хоть и предвиденная, очередная серия экспериментов в VM перед применением решения. Очередные выходные на работе, что вообще-то было в последний раз больше года назад, историю про перенос того же почтовика в Балте в расчет не беру.
Суть проблемы - свободное место. Оно просто кончилось. Фраза "И время мы измеряем в мегабайтах" стала ключевой на всю прошедшую неделю. Раскладка такова: 3 базы по 150 Гб, и еще две по 80 Гб. Плюс папка логов, но это уже сущие мелочи по сравнению с тремя первыми колоссами. Места под них было выделено еще на этапе проектирования сервера и его структуры - как раз 450 Гб, отдельный диск для логов, и отдельный диск для бекапов. Господа удавы, заявляю, время можно измерять в мегабайтах, особенно когда каждый день у тебя начинается с проверки, а сколько же там свободного места осталось. И постоянные мысли - дотянуть бы до выходных, потому что выключить Exchange в рабочий день нереально. А выключать придется. Дотянули. На момент начала работ места там оставалось без малого 500 Мб. Критика, да и только.
Суть действий - перебить RAID-массив на внешнем хранилище, конфисковав место от первой файлопомойки и даровав почтовику еще 1.9 Тб. Это убьет файлопомойку, но она нам уже не так нужна, почта важнее. Сказано, сделано - в 11 часов субботы базы почтовика были выключены.
Сама по себе процедура подготовки перенесения баз не так уж и сложна. Вкратце ее можно обрисовать следующим образом:

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

- проверка состояния баз программой eseutil
Eseutil /mh
Проверять нужно каждый файл. На этом этапе интересуют параметры
State: Clean Shutdown (чистое отключение)
Log Required: 0-0 (0x0-0x0) (непримененные логи)
О состояниях чистого или грязного отключения и непримененных логах мне уже писать доводилось. Из личного опыта: в состоянии чистого отключения непримененных логов нет.

После отключения баз и проходит их перемещение туда, где они и будут жить, перемещаются файлы *.edb и *.stm. Опять же из личного опыта: базы в чистом отключении при переносе не требуют для себя ни перемещения логов, ни перемещения chk-файла всей группы хранения. Это добро будет создано заново. Тем не менее, наличие резервной копии - ОБЯЗАТЕЛЬНОЕ условие для проведения операции в целом, мало ли что.

В общем и целом, большую часть времени (что в субботу, что в воскресенье) мы провели тупо медитируя на прогресс-бар перемещения баз. Шутка ли, полтерабайта тащить из одного каталога в другой. Да еще прибавить к этому время на переразбиение RAID - но это уже ночью, слава всему святому, что за ночь эта операция прошла успешно. Объясню, почему.
На время работ с внешним хранилищем базы надо куда-то девать. Тащить их по сети в режиме Ethernet 100 - убиться, скорость нас будет тормозить. Поэтому решили содрать их на USB харды. Две штуки по 400 Гб нам хватит. Подключили два харда, слили на них базы (вся суббота на это и ушла), после чего поставили на Expand RAID-массив. И вот тут наши челюсти на пол и упали. Скорость расширения массива - 1% за полчаса. Прикинули - 100% за 50 часов, это получится, что только к понедельнику, к вечеру, и то не факт, у нас завершится подготовка массива. А ведь в понедельник почта уже должна работать.
Кто-то может предложить, а почему эти базы за ночь не слить куда-то в сеть и подключить их по сети к самому Exchange. Отвечу, когда-то давно у меня тоже такая мысль была, но Экс - штука весьма разборчивая. Его базы могут храниться только на DAS-устройствах. DAS - Directly Attached Storage. В эту категорию попадают собственно обычные харды, устройства, подключенные через SCSI-интерфейс, и USB устройства. Из этого многообразия у нас было все, но:
1. Хард самого сервера - это SCSI диск на 45 гигов.
2. SCSI-хранилище - оно сейчас как раз в стадии переразбиения.
3. USB-харды. Дааа, вот тут интересно, поскольку уже на полном серьезе прорабатывали возможность поднятия Exchange "на флешках". Подобной жести у меня в жизни еще не было, и в самом страшном кошмаре не снилось. Почему кошмар? USB-хард, подключенный по проводу к серверу - не шибко надежен. А о том, что случается, когда сервер Exchange вдруг во время работы теряет связь с почтовыми базами, я уже тоже писал, кажется.
В общем и целом, в воскресенье я шел на работу в полной уверенности, что этот кошмар прорвется в жизнь. Нет, повезло, массив переразбился, свободное место получено, можно и заливать базы назад.
Дальнейшее - тривиально: определение того, где будет лежать каждая база, подключение баз в оснастке Exchange, небольшая донастройка всего хозяйства (переименование групп хранения, небольшая их переконфигурация), проверка работоспособности почты.

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

@музыка: Dagda - Anthem Of The Gods

@темы: MS Exchange

---

Autorun

За вполне безобидным и даже удобным механизмом Windows скрывается весьма и весьма сильная головная боль неподготовленных пользователей, а порой и админов. Автозапуск. Да, да, тот самый авторан, который автоматом проигрывает наши CDA диски, сразу же начинает просмотр галерей на флешках и т.п. Само собой, что этот механизм можно использовать и в не совсем добрых целях.
Стандартная мера отключения данной напасти в домене - групповые политики и запрет функции Autoplay на всех дисках. Но есть один подводный камень - этого недостаточно. Блуждая по страницам форумов наткнулся на очень хорошее описание того, что еще можно порубить, дабы оградить себя от атаки классических файловых вирусов:
Клац!
4 ключа реестра, и автозапуск затыкается навсегда.
Единственное, что я еще пока не применил к домену - это удаление ключей MountPoints. В силу того, что я не знаю, как оно работает, и как найти все экземпляры данного параметра на уровне скрипта - пока не рискую. Тем не менее, и вышеприведенных 4 ключей хватило для того, чтобы остановить волну заражений вирусом Sality.aa, вирусом, который именно через авторан и выживает.
Кстати сказать, классические файловые вирусы в наше время ох, как редки. За последние года полтора я вообще не встречал представителей данного класса.

@темы: Viruses and Spam

---

OWA

Outlook Web Access. Весьма удобная функция в составе Exchange, которая мне рушила мозг на протяжении всей прошлой недели. Знать бы, что решение столь простое.
Вводная. После ввода логина и пароля на сайте OWA творится нечто непонятное. Стили улетели в теплые края, список сообщений не загружается, элементы интерфейса aka кнопки "Создать", "Адресная книга" и т.п. не работают. В общем и целом, вместо удаленного доступа к своему почтовому ящику получаешь кукиш с маслом. Это если в Mozilla Firefox, там до писем достучаться все же можно, хоть и криво. В IE нет даже этого, тупая табличка "Loading..." и ничего больше. Вся эта котовасия началась после установки Service Pack 2.
Самое интересное в том, что не мы одни такие несчастные. Интернет просто пестрит постами на форумах с такой же проблемой. Предлагается и просто огромное количество решений, начиная от простой перезагрузки и заканчивая переустановкой SP2. Ни один не помог. Сброс виртуальных каталогов OWA - безрезультатно. Перерегистрация библиотек, отвечающих за обработку XML - туда же. Что за напасть...
И самое интересное, почему в Mozilla Firefox хотя бы часть функционала работает, в то время как в ослике - вообще ноль.
И только сегодня удалось раскопать статью в базе данных MS о том, почему такое могло произойти. Вот она:
Users receive a "Loading" message when they use OWA to access their mailbox after you apply a hotfix or a service pack to Exchange Server 2003 Клац!
Решение просто тривиально... Скопировать один (!) каталог с одного сервера на другой и забыть об этой проблеме...

В то же время так и не понятно, почему в Огнелисе хоть что-то, но работало...

@музыка: David Arkenstone - River Crossing

@темы: MS Exchange

---

Magical 1008 number

После марафона с еще одним восстановлением почтовых ящиков после вторичной аварии на сервере (многовато их что-то) наконец-то начал разгребать весь бардак по резервированию и архивированию информации с Exchange. И нашел в этом одну загвоздку.
Бекап всей информации у нас длился почти 1.5 суток, это очень много. И завершился он в очередной раз неудачей, что для всех, кроме меня, было уже привычным. Стал разбираться, в чем дело. А дело в том, что в процессе резервирования информации почтовые базы данных отключились, то есть стали недоступными. Ни для админов, ни для пользователей, ни для программы архивации. Попытки выяснить причину полного отключения всех баз вывели меня на вот эту статью в базе знаний MS - Клац!
Суть в следующем - при начале архивации базы последняя блокируется для любых изменений на все время архивирования. Все действия, которые должны быть с базой выполнены, сохраняются в файлах логов, которые получают статус Uncommited - непримененные. В системе есть жестко закодированное ограничение на количество таких логов - 1024 штуки (как всегда - по степени двойки). Однако, если этот лимит достигнут, сохранность баз будет под вопросом. Поэтому, если количество непримененных логов достигает 1008 - Exchange самостоятельно принимает попытку сохранения баз данных от повреждения и выполняет т.н. мягкое отключение, базы переводятся в состояние Clean Shutdown, в котором могут быть снова подключены в любой момент. В противоположность этому есть термин "грязное отключение" (Dirty Shutdown), в состоянии которого подключение базы сопряжено с дополнительными действиями, такими, как приведение ее в согласованное состояние и опять же, приведение ее к состоянию Clean Shutdown.
Что же происходит у нас. После того, как на вторые сутки количество непримененных логов превысило критическую величину, базы отключились. Программа архивации, которая до этого момента исправно сливала информацию в бекап, натыкается на недоступность баз, офигевает от такого поворота дел, и отказывается работать дальше, рапортуя об ошибочном завершении задания. В итоге бекапа фактически нет, а та часть, что уже слилась - непригодна для использования в случае краха.
Единственным методом решения данной проблемы является уменьшение времени, необходимое для выполнения всей процедуры резервирования. А вот как этого добиваться, уже вопрос. Лично я пока решил делать резервные копии всех баз, но по-отдельности - одна база за день, это больше, чем трехкратное снижение объема информации. В понедельник - тестовый запуск. Если отработает - распространяю расписание на всю неделю, после чего останется только распланировать сброс архивных копий на ленту и забыть об этой проблеме.

@музыка: Dan Gibson - Whispering Pines

@темы: MS Exchange