Решения второго тура root.yandex.ru

А вот и разбор полетов второго тура Олимпиады сисадминов (ссылка на разбор первого тура). Второй тур немного отличался в деталях от первого - образ был зашифрован на ключе, а не на пароле, вместо Ubuntu Server был CentOS 6.3. В остальном все практически соответствовало первому туру. После развертывания нужно было запустить и организовать OpenVPN соединение по сертификату к серверу проверки заданий. В случае успеха команда получала хэш, который капитан команды должен был ввести на страничке команды. Побеждают те команды, которые раньше всех решат больше всех задач.

Вопросы и решения:

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

Задача похожа на аналогичную из первого тура, только теперь файлы Drupal и его база данных были полностью удалены. В каталоге находились бинарные логи последних операций с MySQL. Сам MySQL также был неправильно сконфигурирован - указан неправильный пользователь. С бинарными логами была небольшая подстава - их было пять штук, причем первый не применялся (обращение к несуществующей базе), а в пятом удалялись данные и полностью удалялась база drupal. Поэтому нужно было осторожно восстанавливать базу, дабы не затереть ее снова. На сайте в итоге создавались три материала, которые проверял сервер проверок. Мы немного провозились с этим заданием, так как в нашей виртуалке было мало выделено памяти, которую Apache полностью выжрал. В результате этого сервер проверок срезался из-за таймаута и некоторое время отдавал отрицательный ответ на правильно решенную задачу.

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

В /boot лежал лишний initramfs, если его распаковать (формат .cpio.gz), то в корне полученного каталога будет лежать файл с ключом.

Эту задачу делал не я, но ее решили простым самописным скриптом. Из подробностей выяснилось, что файл time отдавал nginx, причем этот файл обновлялся bash-скриптом каждые 2 секунды.

Ну это совсем элементарно - еще никто не забыл про сетевую кошку?

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

Эту задачу решали колдуны iptables :). Три команды iptables и дело в шляпе (подробностей уже никто не помнит).

Это была интересная для меня задача. По долгу службы мне часто приходилось восстанавливать данные именно в таких условиях. cfdisk показывал, что в системе три раздела - один под корень, второй - для подкачки, а третий являлся группой томов LVM. Сначала нужно было выполнить автообнаружение LVM (vgchange -a y), после чего находились еще три тома. При детальном изучении оказалось, что это развалившийся массив RAID5 на основе MDADM. Самого mdadm в системе не было (пакет предварительно намеренно был удален), автоматически массив не собирался. Нужно было вручную собрать массив командой mdadm -A (причем поднимались только два диска из трех) и смонтировать его. В корне раздела находился файл с хэшем.

Эта задача была очень выматывающей для нас. По статистике, большинство команд решило эту задачу в последнюю очередь. Эту задачу мы решили только на следующее утро, полностью измотав себя, да и то только с подсказки Civilian. Закончили одиннадцатыми.

Насчет SSH-сессии и неизвестного IP - пыль в глаза. Ее не было. Не зная об этом, мы сперва начали бороздить лог-файлы, запускали антируткиты, потом принялись сличать временные метки, обнаружили, что был изменен файл /etc/aliases.db, кинулись по ложному следу к почтовому серверу (была догадка, что злоумышленник каким-то образом мог воздействовать на систему через него). От отчаяния дошли до того, начали смотреть журналы SELinux. Безрезультатно.

А решение было простым. Нужно было зайти в single-режим (или загрузиться с LiveCD) и внимательно посмотреть на каталог /usr. В нем был каталог /usr/p0wned, внутри которого - файл с ключом и руткит kbeast, замаскированный под модуль ядра intel.ko. Также в системе был инит-скрипт, который подгружал этот модуль в процессе загрузки.

Вот такой для нас была Олимпиада сисадминов. В следующий раз (если соберемся) подготовимся основательнее.