На прошлой неделе мы писали об
уязвимости в системе
безопасности, которая привела к временному отключению некоторых сервисов. На
данный момент все они восстановлены. Мы проанализировали события, которые
привели к взлому и продолжили работу по улучшению безопасности наших систем.
ВАЖНО
Ни в какой момент времени никакие репозитории кода Apache Software
Foundation, загрузки или сами пользователи в связи с этим вторжением риску не
подвергались. Однако мы полагаем, что предоставление деталей случившегося
сделает интернет лучшим местом, позволив другим поучиться на наших ошибках.
Что произошло?
Наша первоначальная теория оказалась верной – сервер, на котором располагался
сайт apachecon.com (dv35.apachecon.com), был скомпрометирован. Машина работала
под управлением CentOS, и мы подозреваем, что они могли использовать недавние
эксплоиты для повышения локальных привилегий, которые были пропатчены в
RHSA-2009-1222. Атакующие полностью скомпрометировали эту машину, получив
root-привилегии и уничтожив большинство логов, что затруднило нам подтверждение
подробностей всего случившегося с машиной.
Владельцем этой машины является компания-организатор конференции ApacheCon, а
не Apache Software Foundation, однако члены Apache Infrastructure Team (AFT)
имеют на ней аккаунты, включая аккаунт, использовавшийся для резервного
копирования.
Нападавшие безуспешно попробовали использовать пароли со скомпрометированного
хоста ApacheCon для авторизации на наших производственных серверах. Позднее,
используя ключ SSH от аккаунта для резервного копирования, они смогли получить
доступ к people.apache.org (minotaur.apache.org). Этот аккаунт был аккаунтом
непривилегированного пользователя, и использовался для создания резервных копий
хоста ApacheCon.
Сервер minotaur.apache.org работает на FreeBSD 7-STABLE и выступает в роли
подготовительной машины для нашей сети зеркал. Это наш первичный shell
account-сервер, на котором находится также много других сервисов для
разработчиков Apache. Код контрольных версий (Subversion) на этой машине не
хранился, поэтому никакой угрозы исходным кодам Apache не было.
Получив shell-доступ, нападавшие добавили CGI-скрипты в корни каталогов с
документами на нескольких наших веб-сайтах. В результате проведения регулярной,
запланированной процедуры rsync эти скрипты были скопированы на наш
производственный веб-сервер, eos.apache.org, на котором они стали видимыми
извне. Эти CGI-скрипты были использованы для получения удаленных шеллов, а
информация посылалась при помощи команд HTTP POST.
Наши страницы загрузки генерируются динамически, чтобы предоставить
пользователям возможность выбрать ближайшее по местоположению зеркало, поэтому
опция ExecCGI у нас включена, что затрудняет защиту от атак подобного
происхождения.
Обнаружив CGI-скрипты, члены AFT приняли решение отключить любые серверы,
которые атака могла потенциально затронуть. В их число вошел сервер
people.apache.org, а также серверы европейского и американского веб-сайтов. Весь
трафик с них перенаправлялся на проверенный сервер, а на отключенных сайтах было
вывешено временное уведомление, дающее людям возможность понять, что мы в курсе
происходящего.
Один за другим мы подняли все отключенные серверы снова, в
однопользовательском режиме, воспользовавшись нашим внеполосным доступом. Очень
быстро выяснилось, что aurora.apache.org, сервер европейского веб-сайта, остался
неподверженным атаке. Несмотря на то, что CGI-скрипты были скопированы на него,
они так не разу и не запустились, поскольку эта машина на момент проведения
атаки не была включена в DNS-ротацию.
Сервер aurora.apache.org работает под управлением Solaris 10, и нам удалось
восстановить на нем безопасную конфигурацию клонированием и активацией
ZFS-копий, сделанных за день до появления CGI-скриптов. Проделав эти операции,
мы быстро вывели европейский сервер обратно в онлайн, после чего оперативно
восстановили наши основные веб-сайты. После этого мы продолжили анализировать
причину взлома, методы получения доступа и ситуацию с возможной компрометацией
других машин.
Вскоре после того, как мы подняли aurora.apache.org , мы определили, что
наиболее вероятное направление взлома связано с процедурой резервного
копирования dv35.apachecon.com. Мы собрали с этого сервера все доступные логи и
быстро отключили его.
Мы также продолжили анализировать minotaur.apache.org и eos.apache.org (наш
сервер в США), пока не получили полную уверенность в том, что все следы атаки
убраны. После того, как сервер признали чистым, он быль вновь выведен в онлайн.
Что сработало?
- Использование ZFS-снимков позволило нам восстановить европейский
производственный сервер к безопасному состоянию. - Избыточное количество серверов в двух местах расположения позволило нам
запустить сервисы с альтернативного месторасположения, продолжив при этом
работу с пострадавшими серверами и сервисами. - Разномастная конфигурация скомпрометированных машин (Linux/CentOS i386,
FreeBSD-7 amd_64 и Solaris 10 на sparc) затруднила нападавшим перспективы по
поднятию привилегий на большом числе машин.
Что не сработало?
- Использование SSH-ключей облегчило проведение атаки. В прошлом их
применение было далеким от идеального, поскольку мы не ограничили
использование ключей SSH надлежащим образом и не отдавали себе отчета в
возможности их неправомерного использования. - Настройка rsync, использующая people.apache.org для управления
развертыванием наших веб-сайтов, позволила нападавшим незаметно скопировать
свои файлы на зеркало в США. - Возможность выполнения CGI-скриптов на любом виртуальном хосте, в то время
как большинству наших сайтов этого не требовалось, подвергла их напрасному
риску быть уязвимыми для подобного рода атак. - Нехватка логов с хоста ApacheCon не позволила с абсолютной достоверностью
восстановить картину действий атакующих. За исключением одного, нападавшие
стерли все логи, кроме того, эти логи не хранились вне скомпрометированной
машины.
Какие изменения мы проводим сейчас?
После вторжения мы проводим ряд изменений для того, чтобы обезопасить нашу
инфраструктуру от подобных инцидентов в будущем. Вот список проводимых нами
изменений:
- Требование ко всем пользователям с повышенными привилегиями использовать
OPIE for sudo на определенных машинах. Это требование уже действует в
некоторых местах, однако теперь данная практика будет обязательно расширена. - Повторное создание и использование SSH, одного для каждого хоста, для
использования при резервном копировании. Также – обязательное использование
опций from="" и command="" в файле авторизованных ключей на сервере назначения
резервного копирования. В совокупности с ограничениями, позволяющими
устанавливать соединения только тем машинам, которые действительно создают
резервные копии данных, данная мера позволит предотвратить возможность
установления SSH-соединений сторонними машинами.- Строка command="" в файле авторизованных ключей теперь является явно
заданной и позволяет осуществлять только односторонний rsync-трафик. - Новые ключи сгенерированы для всех хостов, минимальная длина ключа при этом–
4096 бит.
- Строка command="" в файле авторизованных ключей теперь является явно
- Виртуальная машина, на которой была расположена старая версия сайта
apachecon.com, остается отключенной и ожидает дальнейшего детального анализа.
Сайт apachecon.com вновь развернут на новой виртуальной машине, у нового
провайдера и под другой операционной системой. - Мы рассматриваем возможность отключения поддержки CGI на большинстве систем
с веб-сайтами. Это привело к созданию нового модуля httpd, который будет
управлять предоставлением зеркал для загрузок. - Метод, согласно которому большинство наших публичных веб-сайтов
разворачивается на наших производственных серверах, также будет изменен, этот
процесс станет более автоматизированным. Мы надеемся в течение ближайших
нескольких недель перейти на использование системы, основанной на SvnSubPub /
SvnWcSub. - Мы вновь внедрим на всех машинах практику бана по IP-адресу после нескольких
неудачных попыток авторизации. - Было выдвинуто предложение по введению системы централизованного
журналирования. Эта система включит в себя все логи, и возможно также такие
сервисы, как smtpd и httpd.
Источник:
https://blogs.apache.org/infra/entry/apache_org_downtime_report
