• ↓
  • ↑
  • ⇑
 
Записи с темой: security (список заголовков)
23:24 

Runas command + Internet Explorer 7

В Dash'e под Chronostasis'ом.

IE 6 для администраторов был очень удобен. Тем, что если требуется запустить на клиентской машине несколько программ, от своей учетной записи, не нужно было использовать команду Runas для каждой программы. Достаточно было открыть административный сеанс IE, а в нем уже, набрав, например, С: переместиться к файловой системе компьютера. Типичное применение подобного трюка - установка новых шрифтов в систему, особенно если выгружать сеанс пользователя нельзя, а быстрое переключение выключено (доменная среда).
С приходом Internet Explorer 7 все идет к чертям. Нет, сам браузер по-прежнему можно запустить от административного логина, но возможность ходить по файлам в таком виде компания MS убрала. Зачем - неясно. Но ясен сам факт - дела обстоят не самым удобным для администратора образом.
Логично было бы поступить так: Пуск, Выполнить, и далее ввести команду:
runas /user:< MACHINE or DOMAIN NAME >\< USER NAME > explorer.exe
Но не тут то было. Эта команда не возымеет эффекта.
Решением может стать запуск какой-либо сторонней файловой оболочки, например, того же Total Commander или Free Commander. И в большинстве случаев это даже удобнее. Но есть моменты, где и этот подход бессилен - например, все та же установка шрифтов, простого копирования в каталог %systemroot%\fonts там мало, при установке через проводник происходит еще и регистрация шрифтов в реестре, тот же Тотал на такое неспособен.
Что делать?
Пуск, Выполнить, taskmgr.exe. В появившемся окне Менеджера Задач нужно перейти на вкладку Процессы и завершить процесс explorer.exe, это потушит оболочку, но оставит в фоне все запущенные пользователем программы. Далее необходимо выбрать Файл, Новая задача. А уже там вводить знакомое до боли: runas /user:< MACHINE or DOMAIN NAME >\< USER NAME > explorer.exe. В этом случае открывшееся окно проводника будет в том самом elevated-режиме, то есть с правами того пользователя, от чьего имени было запущено. При этом у нас все так же будет открыто окно диспетчера задач. Его не выключаем. После того, как все административные действия будут выполнены, нажимаем Пуск, Выйти из системы. А после выхода в имеющемся диспетчере задач через меню Файл, Новая задача снова запускаем explorer.exe, но уже в обычном режиме. Все довольны. Пользователь не потерял свои данные и программы, администратор выполнил все необходимые действия с "минимальными потерями".

Еще один вариант решения проблемы кроется в особенности установки IE 7 или IE 8 (если последний был установлен сразу поверх шестой версии). Дело в том, что седьмой и восьмой "ослики" позволяют откатиться назад на шестую версию, и ради обеспечения этой возможности копируют IE 6 в папку %systemroot%\ien, где n - текущая версия IE. И именно оттуда можно достать старый добрый шестой браузер.

@темы: Security

22:07 

WebMarshal 6.x

В Dash'e под Chronostasis'ом.

Что такое WebMarshal? Это контент-фильтр, работающий в паре с прокси-сервером, хотя и сам может выступать в роли последнего. Его задача - более детальное исследование трафика, который идет в Интернет и оттуда, с целью отсечения нежелательного материала. Отличие от обычного прокси в том, что контент-фильтрация режет пользователей не только и не столько по адресам, а по содержанию тех страниц, что пользователи пытаются посетить.
Поработав немного с этой программой и вникнув в ее логику построения правил, нашел ее очень удобной, но есть одна ошибка, которая в последнюю неделю мне попортила изрядное количество крови. Суть ее в следующем.
В своей работе WebMarshal может использовать как свою собственную базу пользователей, так и базу Active Directory. Последнее весьма удобно, не нужно "плодить сущности", как многие говорят. Не буду вдаваться в тонкости организации этой структуры, перейду сразу к делу.
Если пользователь, будучи уже импортированным из Active Directory меняет свое расположение в структуре OU (организационных единиц - читай, в другую перекинули его), при следующем же сеансе обновления информации из Active Directory WebMarshal такого пользователя не найдет. Он упорно будет пытаться найти его в старой OU. Эта ситуация разобрана на самом сайте WebMarshal - вот ссылка на страницу:
Moving Active Directory users between OUs - Клац!

В статье указывается, что проблема эта была решена в версии программы 6.1.6. Не подтверждаю. Используется версия 6.1.7 - ошибка сохраняется. В качестве решения предлагается связаться с технической поддержкой WebMarshal.
Что ж, разумно. В конце концов, тех. поддержка на то и нужна, чтобы решать такие вопросы. Но ведь хочется самому понять, в чем неприятность.
А неприятность заключается в следующем. WebMarshal не работает напрямую с учетными записями в Active Directory. Он создает их реплику в собственной базе. И именно эту реплику он каждый раз обновляет во время синхронизации с Active Directory. Вот только почему-то если WebMarshal видит, что запись в AD обновлена, у себя он не изменяет существующую запись, а создает новую. И все бы ничего, но если попытаться показать список группы, которая содержит переехавшую учетку, это приведет к чтению базы из WebMarshal с ее одновременным обновлением из AD. А в базе WebMarshal будет прочитан сбойный элемент, которого в AD уже нет на старом месте. После чего программа впадает в ступор и выкидывает сообщение об ошибке.
Ручная очистка базы из консоли WebMarshal нужного результата не дает. Сбойная запись по-прежнему где-то сидит и мешает жить. Наконец, было принято решение на свой страх и риск залезть напрямую в SQL базу. Найдя там таблицу dbo.User и открыв ее, я пришел в ужас. Сколько раз была добавлена та учетка, будучи в разных OU, столько раз она и содержалась в базе, несмотря на все сеансы очистки из консоли. Дальнейшее уже тривиально. Смоделировать еще раз ошибочную ситуацию, выписать ID той записи, что сбоит, и грохнуть ее из всех таблиц, которые к этой записи могут относиться.
Согласен, метод весьма жесткий, но иногда приходится действовать и так.

UPD. Только сейчас пришло в голову, что можно и не удалять сбойную запись, а всего лишь выправить значение в поле Name, там, где указывается DN этой записи. В итоге исправление нужно будет вносить только в одной таблице. А это уже куда проще и приятнее для базы в целом.

@темы: Security, Этот безумный мир

21:56 

Windows Update Services #4 (продолжение банкета)

В Dash'e под Chronostasis'ом.

Итак, Client-side targetting. А если по-русски - клиент сам лезет в назначенную ему группу на сервере WSUS, а не администратор его туда определяет руками. Как этого добиться?
1. Создать все требуемые группы на WSUS. Сами они создаваться не будут.
2. При помощи групповых политик назначить компьютерам их группы.
3. Перевести сам WSUS в режим Client-side Targetting, задав еще пару параметров автоматического одобрения обновлений (немаловажный процесс, кстати).
Создание групп на WSUS - дело тривиальное, щелкай себе правой кнопкой в списке групп да имена новосозданным задавай. Переключение режима работы WSUS - не сложнее: Options - Computers - Use Group Policy or Registry setting on computers.
С назначением же групп компьютерам интереснее. Не то, чтобы процесс сильно сложен, просто нужно учитывать один момент, который из моей дырявой головы все же вылетел. Назначение групп политиками делается все там же, где и вся остальная работа с GPO домена - оснастке групповых политик. В том GPO, который регулирует механизм автоматического обновления нужно лишь включить параметр Enable Client-Side Targetting. Там же задается и имя группы, куда будут помещены компьютеры, к которым данная политика применяется. Путь к этой настройке выглядит так:
Computer Configuration, Administrative Templates, Windows Components, Windows Update, Enable Client-Side Targetting.

После того, как политика будет применена к группе компьютеров, все они во время следующего сеанса связи с WSUS переползут в определенную им группу. Все просто. А теперь о том нюансе, который важно не забыть.
Если до включения рассматриваемой настройки компьютеры уже были распределены по группам руками, а после применения оной для определенного числа компьютеров группа оказалась не заданной, то все эти сиротливые машины вовсе не останутся на своих местах (на что я, признаться, очень надеялся). Они довольно быстро переползут в стандартную группу под названием Unassigned Computers, где и будут находиться вплоть до момента назначения им какой-либо группы на WSUS. Признаться, для меня было довольно неслабым шоком, когда я увидел, что все серверы из группы Servers куда-то подевались, а на месте осталась лишь файлопомойка - она просто не успела по-тихому смыться. Пришлось политиками перетаскивать их за шкирки назад.

@музыка: Roxette - Fireworks

@темы: Этот веселый мир, WSUS, Security

01:10 

Windows 7

В Dash'e под Chronostasis'ом.

Установлена, настроена. Введена в местную комнатную сеть. И первая же неприятность - нельзя просмотреть список моих сетевых папок. Вообще нельзя, нет их. Хотя в системе заявлено, что они есть. О доступе на администраторские ресурсы и разговор не идет.
Ковыряния с этой проблемой привели в знакомую до боли еще по временам настройки XP оснастку gpedit.msc.

Local Computer Policy, Computer COnfiguration, Windows Settings, Security Settings, Local Policies, Security Options.
Параметр Network security: LAN Manager authentication level. Читаю его описание и понимаю, что либо врет описание, либо найден баг, и довольно серьезный. Склоняюсь ко второму варианту. В описании указано вот что:

Default:
Windows 2000 and windows XP: send LM & NTLM responses
Windows Server 2003: Send NTLM response only
Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2: Send NTLMv2 response only


На практике же этот параметр по-умолчанию не задан вовсе. Такая настройка просто не позволяет ОС осознать, какой же протокол использовать при аутентификации пользователей сети. Принудительно выставил в Send NTLM response only. После этого сетевые папки стали видны. Одна из частей проблемы устранена, но остается решить, как же включить административные ресурсы.
При попытке доступа на заветный \\COMPUTER-NAME\C$ удаленная система получает отлуп - неверные логин и пароль. В то же время в Управлении Компьютером на Windows 7 показывается, что мой административный пользователь успешно авторизовался и держит открытым сетевой сеанс. Снова бомбим Google поисковыми запросами, в результате чего на одном из форумов натыкаемся на любопытную заметку: Клац!
Суть в том, чтобы создать в реестре парметр LocalAccountTokenFilterPolicy (тип DWORD) по следующему пути: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System. Значение параметра - единица.
После перезагрузки доступ к административным ресурсам появился как по волшебству.

Любопытен тот факт, что согласно заметке на форуме, эта проблема тащится еще со времен ОС Vista, но лично я с ней там не сталкивался...

@музыка: Blue Stone - Dreamcatcher

@темы: Security

21:46 

Windows Automatic Updates #3

В Dash'e под Chronostasis'ом.

Снова WSUS, будь он неладен. Хотя нет, WSUS-то как раз спокойно работает, раздает обновки и есть не просит. А вот тот самый разношерстный бардак на клиентской стороне...
Windows XP Service Pack 3, SP3 в просторечии так же, как и обычные мелкие заплатки может быть распространен посредством системы обновлений. Но поскольку эта "запчасть" весьма немалая, с ней могут возникнуть проблемы. Одна из таких, весьма неприятных, выглядит следующим образом. Клиент закачивает к себе файлы обновления, ждет условленного времени на установку. После наступления минуты "Х" начинает инсталляцию и буквально сразу прерывает ее, снова становясь в режим ожидания следующего интервала установки. В журналах при таком развитии событий пишется ошибка с кодом 0x80070005. Код этот обозначает нехватку прав.
МС написали по данной проблеме весьма подробную статью в базе знаний, вот она:
При попытке установить пакет обновления 3 (SP3) для Windows XP выводится сообщение об ошибке: "Отказано в доступе" или "Установка пакета обновления не завершена" - Клац!

Сценарий, описанный в третьем способе, сбрасывает разрешения на реестр и файлы на "заводские". Это и обеспечивает неограниченный доступ службы обновлений к нужным ей ресурсам.
Все бы ничего, но указанный скрипт некорректен для Windows XP. В нем указывается файл defltbase.inf, которого в системе просто не существует. Как быть? Поиски во всемирной сети снова дали свой результат, скрипт преобразился вот к такому виду:
Reset.cmd

Как это все запустить? Прежде всего, понадобится установочный диск с Windows XP. В дистрибутиве есть хороший набор утилит, называемый Windows Resource Kit. Устанавливаем этот набор, после чего копируем из него одну программу - subinacl.exe Именно она и является ключевым инструментом. Создаем cmd-файл, приведенный выше, сохраняем его рядом с subinacl.exe. Пакет для ремонта разрешений готов. Осталось только его запустить на том компьютере, где наблюдается проблема. Исполняться сценарий будет довольно долго, до десятка минут.

@музыка: G.E.N.E. - Faru Love Affair

@темы: Security, WSUS

21:02 

Windows Automatic Updates #2

В Dash'e под Chronostasis'ом.

Итак, после атаки Kido эту службу требуется снова поднять из пыли, отряхнуть и поставить на место. Проблема решаема при помощи принудительной установки типа запуска службы в "Автоматически". В этом случае после перезагрузки компьютера служба поднимется сама.
Easier said than done. На выходе получаем ошибку следующего содержания: Ошибка 0x80004015: Класс настроен на использование идентификатора безопасности, отличного от используемого вызывающей стороной.
После чего служба послушно становится автоматически запускаемой, но запускаться не желает, в списке служб гордо красуется надпись Stopped.
С этой проблемой я столкнулся еще ранее, как раз пытаясь службу включить принудительно, но поняв, что политика рушит функционал, просто снял ее, тем самым восстановив статус-кво. На этот раз надо все же докопаться до причины. В прошлый раз у меня на руках не было кода ошибки, теперь же он есть.
Что делать? Правильно, спросить решение у всемогущего Google. Великий и тут не подвел, ответ нашелся довольно быстро:
WU client failed to initialize with error 0x80004015 - Клац!
Если по-русски, то получается следующее.
При принудительном включении службы через доменные политики изменяется набор прав на эти самые службы. Политика по умолчанию предлагает проставить следующие разрешения:
Система (System) - полный доступ;
Администраторы (Administrators) - полный доступ;
Интерактивный вход (Interactive, читай, зашедший пользователь, не относящийся к первым двум категориям) - только чтение состояния.
Все. А на деле нужно проставить еще одну сущность, имя которой NetworkService:
В результате должно получиться:
System - полный доступ;
Administrators - полный доступ;
NetworkService - полный доступ;
Interactive - только чтение состояния.
Дальнейшее - тривиально. Определить область действия политики, подключить ее к домену и просто подождать, пока перезагрузятся системы.

Важно! Функционал автоматического обновления системы использует в своей работе две службы - Automatic Updates (Автоматическое обновление) и Background Intellegent Transfer Service (Фоновая интеллектуальная передача данных). Соответственно, принудительно включать надо их обе.

@музыка: Nickelback - If Today Was Your Last Day

@темы: WSUS, Security

22:55 

Kido #4 - Предупреждение.

В Dash'e под Chronostasis'ом.

Trend Micro.Inc - New Version of Conficker
Покой нам только снится. С недавних пор я достаточно часто бываю на сайте своего антивирусного вендора (странно, да? ;), отслеживаю изменения версий антивирусных баз и движка сканера. Все жду, когда же версия выше, чем 8.911 появится на серверах ActiveUpdate. Пока что нет.
Внимание привлек заголовок с уже ставшим ненавистным словом - Conficker. Ссылка на статью выше. Если вкратце - 7 апреля обнаружена новая версия вредоноса, судя по тому, что она попалась в ловушку компании Trend Micro - пятое поколение червя снова научили размножаться (версии С и D не распространялись по сетям). Пути распространения остались теми же - уязвимость, флешки, P2P-соединения.
Паниковать не стоит, но быть в курсе - обязательно.

P.S> На момент составления записи страница с новостью не отзывалась, выдавая ошибку базы данных - Error establishing a database connection. Видимо, популярной оказалась.
P.P.S> 10.04.2009 - статья доступна для ознакомления. Так что рекомендую.

@музыка: Nickelback - If Today Was Your Last Day

@темы: Security, Viruses and Spam

00:02 

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

В Dash'e под Chronostasis'ом.

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

- Доменная сеть, серверы на 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

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

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

RunKiller.bat

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

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

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

@темы: Security, Viruses and Spam

23:28 

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

В Dash'e под Chronostasis'ом.

Лечение сети. Как уже ранее было написано, первое - это серверы. Их еще три. Впрочем, это уже намного меньше, чем в начале вакханалии. Основная проблема кроется даже не в самой процедуре лечения, не в том, что нужно еще найти, как убивать вредоноса. Нет, проблема в пользователях. Самое парадоксальное - их и винить не в чем, в конце концов, тот факт, что блокировка учетных записей идет почти непрерывно - всецело "заслуга" 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
Я искренне надеюсь, что никому его не придется применять. Борьба с Kido - вещь все же выматывающая.

@музыка: Madonna - Rain

@темы: Viruses and Spam, Security

15:20 

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

В Dash'e под Chronostasis'ом.

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

@темы: Security, Viruses and Spam

Записная книжка

главная