Жизнь после взлома

Восстановление после сетевой атаки

Наконец-то пятница! Администратор предвкушает заслуженный отдых, но перед самым окончанием рабочего дня кто-то из пользователей внезапно жалуется на медленную работу сети, особенно при попытках доступа в Internet. Проверка показывает, что сервер и сеть и в самом деле работают невероятно медленно. Тогда администратор проверяет статистику трафика через брандмауэр и замечает необычно высокий уровень Internet-трафика. Затем он запускает на сервере команду Netstat и обнаруживает несколько неавторизованных подключений к корпоративному серверу, причем все указывает на то, что подключились из Internet. Администратор проверяет реестр сервера и здесь также замечает несколько неизвестных программ, запуск которых производится автоматически. О планах на долгожданные выходные можно забыть: предстоит приятный уикенд на рабочем месте. Сеть только что взломали!

В зависимости от природы атаки не всегда просто определить, что именно было взломано. Если знать, куда смотреть и что искать, это может здорово помочь вовремя обнаруживать атаки и принимать меры к устранению угроз до того, как произойдут дополнительные разрушения. В этой статье я расскажу о том, где начинать искать вредоносные программы, способные вывести систему из строя, и предложу примерный план восстановления системы после атаки хакеров. Будут рассмотрены три случая использования различных тактических приемов, которые могут помочь обнаружить взлом сети и восстановить сеть после него, а также предотвратить атаки в будущем.

Где смотреть

Очевидно, что, прежде чем предпринять что-либо для остановки атаки и восстановления системы, необходимо отыскать место взлома. С чего начать? Каждый взлом по-своему неповторим, но есть несколько мест, которые следует проверять в первую очередь. Перечислим их.

Разделы реестра. Если есть подозрение, что была взломана отдельная система, первыми следует проверить разделы Run на этой машине. Необходимо посмотреть, не запускаются ли из этих разделов какие-либо незнакомые программы. Разделы Run — излюбленное место запуска вредоносных программ не только у хакеров, но и у создателей вирусов, которые также запускают из этих разделов свои «произведения». Разделы Run поддерживаются на платформах Windows Server 2003, Windows XP, Windows 2000, Windows NT, Windows Me и Windows 9x. Вот список этих разделов:

HKEY_LOCAL_MACHINESOFTWAREMicrosoft WindowsCurrentVersionRun
HKEY_LOCAL_MACHINESOFTWAREMicrosoft WindowsCurrentVersionRunOnce
HKEY_LOCAL_MACHINESOFTWAREMicrosoft WindowsCurrentVersionRunServices
HKEY_LOCAL_MACHINESOFTWAREMicrosoft WindowsCurrentVersionRunServicesOnce
HKEY_CURRENT_USERSoftwareMicrosoft WindowsCurrentVersionRun
HKEY_CURRENT_USERSoftwareMicrosoft WindowsCurrentVersionRunOnce
HKEY_CURRENT_USERSoftwareMicrosoft WindowsCurrentVersionRunServices
HKEY_CURRENT_USERSoftwareMicrosoft WindowsCurrentVersionRunServicesOnce

Если используются системы Windows 2003, XP, Windows 2000 или NT, необходимо также проверить раздел HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows CurrentVersionPoliciesExplorerRun.

Любая неизвестная программа, в принципе, может оказаться программой взлома. С помощью Google или другой машины поиска нужно попробовать отыскать в Internet программу с аналогичным именем и выяснить, является ли она легитимной. Особое внимание следует обратить на программы, которые запускаются из C:, C:windows и C:windowssystem32. Я очень рекомендую всем администраторам приобрести привычку регулярно просматривать указанные разделы реестра и знать «в лицо» все программы, которые загружаются на компьютере автоматически.

Перечисленные ниже разделы используются для запуска программ взлома не так часто, но их тоже следует держать под контролем. Эти разделы также применяются во всех версиях Windows. Если раздел реестра по умолчанию (раздел default) содержит что-то, отличное от записи «%1» %*, очень вероятно, что речь идет о программе взлома.

HKEY_CLASSES_ROOTatfileshell opencommand
HKEY_CLASSES_ROOTcomfileshell opencommand
HKEY_CLASSES_ROOTexefileshell opencommand
HKEY_CLASSES_ROOThtafileshell opencommand
HKEY_CLASSES_ROOTpiffileshell opencommand
HKEY_LOCAL_MACHINESOFTWAREClassesatfile shellopencommand
HKEY_LOCAL_MACHINESOFTWAREClassescomfile shellopencommand
HKEY_LOCAL_MACHINESOFTWAREClassesexefile shellopencommand
HKEY_LOCAL_MACHINESOFTWAREClasseshtafile shellopencommand
HKEY_LOCAL_MACHINESOFTWAREClassespiffile shellopencommand

Службы. Необходимо просмотреть раздел реестра HKEY_LOCAL_

MACHINESYSTEMCurrentControlSetServices во всех версиях Windows. Записи в этом разделе специфицируют службы, описанные на компьютере. Я рекомендую взглянуть на список служб именно в реестре, а не через графический интерфейс Windows Services, поскольку некоторые службы (например, службы типа Type 1) там не показаны. И опять-таки следует внимательно отнестись к неизвестным программам. Если возможно, сравните записи раздела Services «подозреваемого» компьютера и аналогичные значения на станции, заведомо не взломанной, — могут обнаружиться важные отличия.

Каталог Startup. Требуется проверить каталоги C:Documents and SettingsAll UsersStart Menu

ProgramsStartup и C:Documents and Settingsuser_name>Start MenuProgramsStartup на предмет поиска неизвестных программ и скрытых файлов. Для получения списка скрытых файлов текущего каталога и всех подкаталогов нужно набрать в командной строке:

dir /a h /s

Планировщик (Task Scheduler). Следует проверить каталог C:windows asks на запланированные задания. Внимательно исследуйте все неизвестные задачи планировщика.

Win.ini. Для атаки могут автоматически запускаться программы взлома из C:windowswin.ini. Необходимо проверить содержание следующей секции в файле win.ini:

[windows]

Run=

Load=

Любая программа, указанная после Run= или Load=, будет автоматически загружаться при запуске Windows.

System.ini. Злоумышленники могут воспользоваться загрузкой программ из C:windowssystem.ini. Следует проверить содержимое секции

[boot] shell=explorer.exe

Любая программа, указанная после explorer.exe, будет автоматически загружаться при запуске Windows.

Существуют и другие места, откуда хакеры могут запускать программы автоматически при запуске Windows. Бесплатная утилита Autoruns (разработчик — Sysinternals) покажет, какие программы на станции настроены на автоматическую загрузку во время запуска NT или более поздних версий Windows. Загрузить эту утилиту можно по адресу http://www.sysinternals.com/ntw2k/ freeware/autoruns.shtml.

Открытые порты и неавторизованные пользователи

После проверки хакерской активности в перечисленных выше разделах нужно проверить открытые порты, которые не должны быть открытыми.

Существуют программы-невидимки (так называемые root kits), которые запускаются на уровне операционной системы и открывают порты на скомпрометированной машине, которую нарушитель использует для удаленного доступа. Root kits типичны для мира UNIX, но все чаще встречаются аналогичные программы для взлома Windows. Чтобы определить, какие подключения в данный момент имеются к данному компьютеру и какие порты прослушиваются на хосте Windows, нужно открыть окно командной строки и запустить команду

Netstat -a

Таблица 1. Типичные открытые порты для станции XP

В табл. 1 перечислены порты, которые обычно открыты на хосте XP. Не стоит паниковать, если на рабочей станции или сервере окажется больше открытых портов, чем перечислено в табл. 1. Порты могут динамически назначаться в зависимости от типа запущенной службы. Например, удаленный вызов процедур (RPC) использует динамически открываемые порты, когда выполняется удаленное администрирование DHCP и серверов WIN. Подробнее об этом рассказано в статье Microsoft «How To Configure RPC Dynamic Port Allocation to Work with Firewall» по адресу http://support.microsoft.com/ ?kbid=15459. При запуске Netstat особое внимание необходимо уделить следующим обстоятельствам:

большое число (10 и более, в зависимости от типичных условий работы) установленных соединений, особенно если они выполнены по IP вне вашего офиса;
необычные номера открытых портов, особенно если это старшие номера портов (выше 1024). Программы взлома и root kits часто используют старшие номера портов для установления удаленных соединений;
большое число отложенных попыток подключений свидетельствует о возможной SYN-атаке;
BAT-файлы неизвестного происхождения. Некоторые root kits создают BAT-файлы в каталогах C:, C:winnt, C:windows, C:winntsystem32 и C:windowssystem32. Root kits и другие неавторизованные программы могут также создавать файлы и каталоги в Recycle Bin, поэтому нужно обращать внимание на скрытые и неизвестные каталоги внутри папки Recycle Bin. По умолчанию файлы Recycle Bin размещены в каталоге C: ecycler. Весьма подозрительно, если файлы и каталоги остаются в Recycle Bin после того, как эта системная папка будет очищена.

Некоторые утилиты взлома могут блокировать работу Netstat и мешать отображать открытые порты на компьютере. Если Netstat не показывает в открытых портах ничего необычного, но подозрения на этот счет все-таки остаются, нужно запустить с другого компьютера утилиту Open Source Network Mapper (nmap), которую можно загрузить из Internet по адресу http://www.insecure.org/nmap, и посмотреть на открытые порты данной станции.

Мошенники в AD. Когда нарушитель компрометирует систему, он может создать одну или несколько своих учетных записей в Active Directory (AD). Нередко нарушители создают такие учетные записи, не заполняя поле описания (description) пользователя. Чтобы противостоять подобной тактике, советую добавлять данные в поле description (следуя при этом специфическим правилам именования) для каждого авторизованного пользователя AD. Это позволит отсортировать учетные записи пользователей AD по полю description, и все записи с пустым полем описания появятся в самом верху списка.

Неавторизованные пользователи в привилегированных группах. Одна из главных задач взломщика заключается в получении привилегированных прав доступа. Необходимо проверить содержимое таких групп AD (например, Administrators, Domain Admins, Enterprise Admins, Server Operators) на наличие неавторизованных учетных записей. Требуется создать ограничения членства в привилегированных группах, чтобы всегда можно было быстро обнаружить неавторизованных членов.

План восстановления после взлома

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

Изолируйте сеть. Требуется отключить все внешние сетевые интерфейсы, в том числе Internet, WAN, VPN и коммутируемые, отключить все линии маршрутизатора, беспроводные точки доступа Access Points (AP) и любые другие устройства, которые соединяют сеть с внешним миром. Это действие позволит остановить активную атаку и помешает нарушителю скомпрометировать другие системы.
Выполните проверку текущего состояния беспроводной сети. Необходимо воспользоваться беспроводным снифером, например Airscanner Mobile Sniffer или NetStumbler.com NetStumbler, для локализации «скомпрометированной» AP. Важно убедиться, что снифер установлен на сетевой карте, которая поддерживает все текущие беспроводные стандарты (т.е. 802.11a, 802.11b и 802.11g).
Проверьте остальные скомпрометированные машины. Следует использовать методы, описанные в данной статье, для поиска других скомпрометированных машин.
Проанализируйте настройки брандмауэра. Необходимо обратить внимание на незнакомые правила, незаконно открытые порты для связи с внешним миром и неавторизованные правила Network Address Translation (NAT). Требуется проверить журналы брандмауэра на любую подозрительную активность. Рекомендую всегда ограничивать исходящий трафик только строго необходимыми портами и разрешать отправлять почтовые сообщения с ограниченного числа компьютеров через брандмауэр.
Проинспектируйте AD. Нужно обратить внимание на неавторизованные учетные записи пользователей и, если таковые найдутся, отключить их.
Организуйте принудительную смену паролей для всех учетных записей в сети. Для учетных записей с высокими привилегиями рекомендую создать пароль (или некую ключевую фразу) по крайней мере из 15 символов. Пароли такой длины тяжелее взломать, поскольку хеши паролей LAN Manager (LM) не сохраняет на сервере, если длина пароля превышает 14 символов.
Замените жесткие диски взломанных систем. Замена дисков изолирует и останавливает хакерскую активность. Данные на старых дисках всегда можно потом просмотреть и извлечь ценную информацию об атаке.
Идентифицируйте и ликвидируйте выявленное слабое место. Важно установить, каким образом хакер получил доступ в сеть. Как правило, это проще сказать, чем сделать. Если идентифицировать уязвимость не удастся, стоит подумать о привлечении консультанта по безопасности для оказания помощи.
Заново переустановите скомпрометированную машину. Полностью очистить взломанный компьютер практически невозможно. Если один или несколько инструментов взломщика осталось на компьютере, нарушитель снова может перехватить управление станцией. Единственный способ гарантированно очистить пораженный компьютер — отформатировать жесткий диск и переустановить все с нуля, при этом надо убедиться, что при восстановлении не будут установлены ранее обнаруженные инструменты взлома. Все программы желательно переустановить с компакт-диска, вручную развернуть исправления и восстановить только файлы данных. Никогда не следует восстанавливать реестр, операционную систему или любые другие программы с ленты.
На всех компьютерах запустите программу антивирусного сканирования. Нужно иметь в виду, что антивирусное программное обеспечение может иногда идентифицировать инструменты взлома как вполне законные программы. Если сканирование показало, что все чисто, но в этом есть хоть какие-то сомнения, рекомендую установить всю систему с нуля.
Заново подключите все линии WAN. Необходимо подключить линии WAN и внимательно следить за данными мониторинга, это поможет убедиться, что пробелы в сети компании устранены. Объект особого внимания — использование полосы пропускания, журналы брандмауэра и журналы аудита на всех серверах.
Проведите тщательное исследование взломанных жестких дисков. Следует установить взломанные жесткие диски на изолированный компьютер и постараться получить как можно больше информации о характере взлома. Хотя злоумышленники часто используют технику спуфинга (получение доступа обманным путем; ситуация, когда пользователь пытается соединиться с Internet-сервером, proxy-сервером или брандмауэром, вводя ложный IP-адрес), адрес IP — то, с чего хорошо начинать выстраивать путь к источнику атаки. Получить список IP-адресов можно на Web-сайте Internet Assigned Numbers Authority (IANA) по адресу http://www.iana.org.
Известите компетентные органы. В США, к примеру, сотрудниками ФБР организован Web-сайт Internet Fraud Complaint Center (IFCC — http://www.ifccfbi.gov/index.asp) для составления отчетов о подозрительной активности в Internet, а большинство региональных отделений ФБР имеют специальные группы противодействия хакерам Cyber Action Teams (CAT). Никто не испытывает особой радости, признаваясь, что его сеть была взломана, однако своевременное оповещение компетентных органов поможет предотвратить еще большие разрушения от действий хакеров. В США, например, можно связаться с ближайшим отделением ФБР по адресу http://www.fbi.gov/contact/ fo/fo.htm.

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

Обучение на примерах

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

Атака на IIS в DMZ

Мне позвонил один из моих клиентов и сказал, что пользователи не могут получить доступ к некоторым каталогам в системе Windows 2000 Server. Когда выяснилось, что для этих каталогов были удалены все права, у меня возникло подозрение на взлом системы.

Идентификация взлома. Я открыл в Microsoft Management Console (MMC) оснастку Active Directory Users and Computers и просмотрел учетные записи пользователей. Кто-то создал странную учетную запись, которая оказалась в составе группы Administrators. Я понял, что нарушитель взломал сеть, поэтому все внешние подключения были моментально отключены и начался всесторонний анализ скомпрометированного компьютера. Это не отняло много времени: мой клиент имел два Web-сервера в демилитаризованной зоне (DMZ). Один из них представлял Web-страницу компании; другой вел согласование времени. Я проверил разделы реестра Run и обнаружил подозрительные BAT-файлы на диске С на обоих серверах. На сервере с программным обеспечением согласования времени были обнаружены странные FTP- и SMTP-программы и большое число root kits. Этот сервер подключался к системе Microsoft SQL Server по локальной сети и с помощью только трафика от SQL Server передавал данные из DMZ в локальную сеть. Этот сервер представлял собой Windows 2000 с установленным пакетом обновлений Service Pack 2 (SP2) и на нем отсутствовало огромное число критических исправлений для систем Windows 2000.

Ликвидация последствий взлома. Я перестроил сервер «с нуля», перенес его в локальную сеть за брандмауэр и закрыл общий доступ к нему. Затем снова подключил внешние связи и установил мониторинг, отслеживая любую подозрительную активность.

Делаем выводы. Перед тем как помещать публичный сервер в DMZ, убедитесь, что производители программного обеспечения, используемого в вашей системе, выпускают в достаточной мере безопасные продукты для работы в режиме общего доступа. Необходимо поддерживать все серверы, а не только те, что находятся в DMZ, на уровне последних пакетов обновлений и критических изменений. Нужно убедиться, что приложения используют SQL Server-интегрированную систему безопасности и не применяют в коде программ для подключения к серверу SQL строки соединения (connection string — используется в ODBC для соединения с внешней базой данных). Встраивание связывающих строк в код Web-сервера дает злоумышленнику прекрасную возможность получить имя и пароль действующей учетной записи. Подробнее об установлении соединения SQL Server с Web-сервера рассказывается в статье Microsoft «Recommendations for Connecting to Databases Through Internet Information Services» (http://support.microsoft.com/ ?kbid=258939). Следует убедиться, что Microsoft IIS использует хранимые процедуры для получения доступа к данным SQL Server, и не позволять серверу IIS запускать операторы SQL. Поскольку все перечисленные шаги позволяют предоставить аутентифицированному пользователю разрешение Execute только для хранимых процедур, вы тем самым можете предотвратить попытки пользователя запустить операторы SELECT на SQL Server.

Атака на клиента VPN

Еще один мой клиент (с Exchange 2000 Server) столкнулся с трудностями при выполнении работ, связанных с резервированием данных, а также с очень низкой производительностью сервера при отправке и получении электронной почты. Нам удалось выяснить, что причина происходящего более серьезная, нежели сбои в работе драйвера стримера или недостаточно мощный сервер. Сервер демонстрировал непревзойденную дисковую активность и высокий процент использования процессора. Я открыл Windows Task Manager и рассортировал время загрузки процессора по процессам. Store.exe забирал львиную долю времени. В компании не было настолько интенсивно работающего пользователя Exchange и на тот момент было всего-то 15 подключений к серверу. С таким количеством пользователей Exchange не должен был потреблять так много вычислительных ресурсов, и я заподозрил разрушения в почтовом хранилище.

Идентификация взлома. Я запустил Exchange System Manager (ESM) и выбрал Administrative Groups, Admin_Group_Name, Servers, Server_Name, Protocols, Smtp, Default SMTP Virtual Server, Current Sessions. Попутно я замечаю, что шесть сессий подключено к виртуальному серверу SMTP уже не меньше пяти минут — прямая улика, указывающая на то, что кто-то неправильно использует сервер. В типичной ситуации сессия Exchange Server остается активной лишь несколько секунд, если только не производится отправление или прием сообщения с вложением большого объема. Я просмотрел очереди виртуального сервера SMTP по умолчанию и обнаружил более 50 очередей в различных стадиях отправки почты или ожидающих возобновления работы. Кто-то использует почтовый сервер как ретранслятор, но как? На сервере установлен последний пакет обновлений (Windows 2000 SP4 и Exchange 2000 SP3) и самые свежие исправления, поэтому я запускаю тест Open Relay Database (ORDB) (его можно загрузить по адресу http://www.ordb.org; тест проверяет указанные хосты на предмет открытой ретрансляции), дабы убедиться, что ретрансляция закрыта.

Всякий раз, когда я пытался очистить соединение на виртуальном сервере SMTP по умолчанию, оно снова появлялось, обычно с другим доменным именем, но с тем же самым IP. Проверяю этот список адресов IP и узнаю, что он выделен одним из Internet-провайдеров в далеком Китае. Убедившись, что мой сервер не настроен на открытую ретрансляцию, я прихожу к заключению, что кто-то, по-видимому, прошел аутентификацию на сервере и теперь рассылает от его имени сообщения. А процедура Backup выдает сбои, поскольку все время пытается создать резервную копию всего рассылаемого спама. Открываю Active Directory Users and Computers и удаляю записи всех подозрительных пользователей. При этом замечаю, что некоторые неавторизованные пользователи находятся в группе Administrators, и удаляю их. Затем проверяю реестр, но не нахожу ничего предосудительного в разделах Run. На всякий случай запускаю сканирование вирусов — программа сообщает, что сервер чист.

Чтобы не дать спамеру продолжить рассылку новых сообщений, я отключил брандмауэр от Internet и удалил все активные сессии с сервера Exchange. Затем я попытался было с помощью ESM удалить сообщения из очередей печати, но на это ушло бы слишком много времени. Тогда я просто остановил все службы Exchange, открыл окно командной строки и с помощью команды Del удалил все сообщения из каталога D:exchsrvrmailrootvsi 1queue. Как только были остановлены службы Exchange, производительность сервера скакнула вверх. На удаление

10 000 сообщений из очередей ушло более часа. Потом настала очередь «спам»-каталога D:exchsrvrmailrootvsi 1admail. На удаление сообщений из нее ушло еще около 8 часов. И наконец, были изменены все пароли сетевых пользователей и на брандмауэре создано правило для блокировки трафика с диапазона IP-адресов, откуда изначально поступал спам. После выполнения всех изменений я заново подключил брандмауэр к Internet и запустил мониторинг сервера. Поток спама не возобновлялся.

Данная сеть имела несколько удаленных сайтов, которые работали через туннели VPN. На одном из сайтов на удаленной машине были обнаружены следующие программывзломщики: Bat.Mumu.A.Worm, Hacktool, W32.Valla.2048, W32.HLLW. Lovgate.J@mm, Bat.Boohoo.Worm и MSBlast.

Мой клиент сказал, что данный компьютер был включен постоянно, туннель VPN на нем остается активным. В таком случае взлом системы — это только вопрос времени. Я всегда рекомендую, чтобы удаленные клиенты сидели за брандмауэром, особенно если они используют широкополосное подключение. Если у вас система XP соединяется по коммутируемому или беспроводному соединению, необходимо убедиться, что Windows Firewall (прежнее название — Internet Connection Firewall, ICF) защищает компьютер при подключении к Internet.

Ликвидация последствий взлома. Рабочая станция была перестроена заново, помещена за брандмауэр TELE3 (производитель — SonicWALL), и на брандмауэре была настроена возможность создавать обратный туннель к центральному корпоративному офису. К счастью для клиента, злоумышленник использовал сервер только для рассылки спама.

Делаем выводы. Приняв во внимание причины взлома, компания теперь не разрешает на станциях клиентов использовать программное обеспечение Mobile VPN Client на широкополосном соединении без установки брандмауэра. Если у вас есть удаленные сайты с туннелями VPN и широкополосные соединения, следует установить брандмауэр или по крайней мере настаивать на том, чтобы пользователи отключали свои компьютеры, когда в них нет необходимости. Кроме того, надо научить пользователей деактивировать туннель VPN, если он в данный момент не нужен.

Атака на Exchange Server (SMTP AUTH)

В третьем случае клиент, использующий Internet-соединения, сообщил, что обмен происходит очень медленно из-за чрезвычайно интенсивного трафика. После того как я попросил всех пользователей Internet отключиться, трафик по-прежнему остался очень высоким. Я посмотрел статистику исходящих очередей на сервере Exchange 2000 и обнаружил более 100 очередей, причем в каждой очереди присутствовало большое число сообщений. С помощью ESM я проинспектировал сообщения в нескольких очередях. Выяснилось, что в них присутствовали сообщения, в которых отправитель и получатель не принадлежали локальному домену, и это означало, что почтовый сервер использовался наподобие ретранслятора почтовых сообщений. По умолчанию Exchange 2000 и более современные системы допускают ретрансляцию, если отправитель сообщения может успешно пройти аутентификацию на почтовом сервере.

Идентификация взлома. Хакеры могут применять целый набор различных методик для захвата имени пользователя и его пароля. Например, они могут периодически пытаться угадать гостевой пароль или пароль реального пользователя и делать это до тех пор, пока не улыбнется удача или не получится запустить программу взлома для захвата имени и пароля пользователя. Спамеру достаточно заполучить одно-единственное правильное имя и пароль, и тогда уже все равно, настроен почтовый сервер на ретрансляцию или нет.

Чтобы установить, какую учетную запись использует спамер, я запустил ESM и открыл Organization, Administrative Groups, Organizational Unit, Servers, затем перешел в контекстное меню Server Name, Properties и на вкладку Diagnostics Logging. В окне Services я щелкнул MSExchangeTransport и в окне Categories повысил уровень регистрации событий до максимума для категорий Routing Engine, Categorizer, Connection Manager, Queuing Engine, Exchange Store Driver, протокола SMTP и драйвера хранилища NTFS. Затем я щелкнул Event Log и обратил внимание на наличие событий аутентификации от внешнего или неизвестного почтового сервера. Неудачные попытки выполнить регистрацию отображаются в журнале Security Log с кодом ID 680. Я обнаружил, что в процессе аутентификации на почтовом сервере злоумышленник использовал учетную запись, которая не была локальной учетной записью Exchange Server.

Ликвидация последствий взлома. После того как была идентифицирована учетная запись, через которую шла аутентификация, я предпринял следующие шаги для обеспечения безопасности сервера Exchange.

Изменил пароль учетной записи, которую использовал спамер. Если предположить, что спамер мог воспользоваться несколькими учетными записями, тогда можно поменять пароли для всех пользователей сети. Также была отключена учетная запись Guest и установлены выделенные учетные записи для запуска служб на сервере. Не стоит использовать запись Administrator для запуска служб. Если машина будет взломана, учетная запись, от имени которой запускается служба, может быть скомпрометирована.
Отключил аутентификацию на внешнем сервере Exchange. Для этого нужно запустить ESM и выбрать Organization, Administrative Groups, Organizational Unit, Servers, Server Name, Protocols, SMTP, затем открыть контекстное меню виртуального сервера SMTP по умолчанию, выбрать Properties, перейти на вкладку Access и щелкнуть Authentication. Я оставил Anonymous Access включенным, но снял флажки Basic Authentication и Integrated Windows Authentication. Снятие этих флажков фактически приводит к тому, что на SMTP-сервере отключается команда Auth.
Включил ретрансляцию для остальных внутренних серверов Exchange, чтобы убедиться, что они могут посылать почту на внешние (outward-facing) серверы Exchange. Для этого нужно запустить ESM, открыть контекстное меню виртуального сервера SMTP и выбрать Properties. На вкладке Access следует щелкнуть Relay, выбрать Only the List Below и перечислить внутренние почтовые серверы, которым разрешается ретранслировать почтовые сообщения на внешние серверы.
После всех этих изменений я провел строгое тестирование полученной конфигурации. Был протестирован входящий и исходящий почтовый Internet-трафик, а также почтовый трафик между серверами внутри компании. Изменения теоретически могли нарушить поток почтовых сообщений между серверами, поэтому есть смысл для проведения подобных работ дождаться выходных. А еще лучше проверить внесенные изменения в лабораторных условиях до реального воплощения в бизнес-среде.
В данном случае обнаружилась станция, которая оказалась очень серьезно скомпрометирована, ее пришлось перестраивать «с нуля». В какой-то другой ситуации может потребоваться идентифицировать все скомпрометированные станции и либо попытаться их восстановить, либо перестроить заново.
Проверил ORDB для того, чтобы установить, не оказался ли клиент почтового сервера занесенным в «черный список» для ретрансляции сообщений. К счастью, я обнаружил и ликвидировал последствия взлома до того, как почтовый сервер клиента был занесен в «черный список». Почтовый сервер может быть помещен в «черный список», если ретрансляция открыта или если почтовый сервер идентифицируется как сервер, который посылает огромный объем данных, идентифицируемых как спам. Существует множество баз данных открытой ретрансляции. Посмотреть список некоторых баз данных можно по адресу: http://dmoz.org/computers/internet/abuse/ spam/blacklists.

Когда почтовый сервер помещается в «черный список», администратору остается или послать запрос об удалении сервера из «черного списка», или изменить внешний адрес IP своего почтового сервера. Если решено изменить адрес почтового сервера, то необходимо также обновить запись Mail Exchanger (MX) Record на этом сервере, иначе исходящая корреспонденция будет блокироваться.

Делаем выводы. Чтобы восстановить Exchange Server после атак типа SMTP AUTH и не допустить их повторения в будущем, я строго рекомендую выполнить все перечисленные выше шаги. Если злоумышленник каким-либо образом раздобыл истинное имя и пароль пользователя и умеет организовать ретрансляцию почты, тогда почтовый сервер вскоре окажется в «черных списках» электронной почты. Вы потратите гораздо меньше времени на предотвращение подобных атак, чем на выяснение причин, связанных с ненормальной рассылкой почтовых сообщений, путем удаления своего сервера из «черных списков» и ликвидации уязвимых мест.

Не нужно паники — просто будьте начеку

План восстановительных мероприятий после проведенной атаки — это часть любой ИT-структуры. Он поможет отыскать эффективный путь противодействия атакам на сеть. Ознакомьтесь с утилитами и методами, которые используют злоумышленники, и не пренебрегайте профилактическими мерами против атак на сеть.

Что почитать дополнительно

WINDOWS IT PRO RESOURCES

Для быстрого ознакомления с различными аспектами в области безопасности:

Security Administrator newsletter http://www.windowsitpro.com/windowssecurity/ issues

Более подробные сведения об атаках типа «спам»:

«A New Kind of Attack,» InstantDoc ID 40507

Аудиопрезентация (Webcast) о защите организации от угроз безопасности:

Microsoft Security Strategies Roadshow http://www.winnetmag.com/roadshows/c omputersecurity2004

Другие ресурсы:

Intrusion Detection FAQ http://www.sans.org/resources/idfaq

Интерактивные ресурсы

Зайдите на сайт www.windowsitpro.com и введите в поле InstantDoc ID номер 43875

October 13, 2004, 12:00 noon EST:

Беседа со специалистом Windows IT Pro Аланом Сугано (Alan Sugano) о способах обнаружения взлома и восстановления системы

October-December 2004:

Беседа с Бреттом Хиллом о противодействии хакерам и решении некоторых других проблем безопасности

Заметки Паулы Шерик «Lessons from the Cyber Trenches»

Алан Сугано (asugano@adscon.com) — президент компании ADS Consulting Group, специализирующейся на сетевых технологиях, программировании, проектировании на базе Microsoft .NET и SQL Server