We rise up for the things we believe in over and over again

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

We rise up for the things we believe in over and over again

Можно сказать, экзамен выдержал. Очередная проблема с 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

22:09

Autorun

We rise up for the things we believe in over and over again

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

@темы: Viruses and Spam

19:36

OWA

We rise up for the things we believe in over and over again

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

We rise up for the things we believe in over and over again

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

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

@темы: MS Exchange