Пост написан по мотивам публикации «Живительная флешка».

Предисловие

Доброго времени суток, Хабр. Совсем недавно, читая Хабр, наткнулся на статью Живительная флешка, где был описан способ создания мультизагрузочной флешки с набором полезных утилит, разнообразных систем и т.д. И все бы ничего, да вот и тут зарыта собака — обратим внимание на эту ветку комментариев, в которой обсуждается работоспособность мультизагрузки в системах с UEFI. Таким образом я начал собственное расследование искать универсальный способ решения этой проблемы.

На сегодняшний день самыми популярными дистрибутивами для тестирования на проникновение являются *nix-like дистрибутивы: Kali Linux, BlackArch Linux, Pentoo, Whonix и многие другие. Они могут использоваться как в виртуальной среде, так и в качестве live системы или вообще быть установлены в виде десктопной ОС.

Windows пользователи до недавнего времени были обделены (виртуальные машины не берем во внимание) такими сборками, пока не появилась волшебная коробочка — PentestBox.

Требуемое программное обеспечение: Kali Linux.
Необходимые знания: опыт работы с консолью Linux-систем (в частности, дистрибутивом Kali Linux) и консолью Метасплойта.

В первой части мы познакомились с модулями для обнаружения уязвимостей при аутентификации (SMB Login Check, VNC Authentication None Detection) и плагином для поиска уязвимостей в веб-приложениях (WMAP). Во второй части займемся установкой сканера уязвимостей Nessus на 32-битную версию системы Kali Linux для последующего его взаимодействия с Метасплойтом (установка на 64-битную версию происходит аналогичным образом).

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

Установка Nessus Home

Nessus — один из самых популярных сканеров уязвимостей, разработанный компанией Tenable Network Security. До 2005 года это было свободное программное обеспечение с открытым исходным кодом, а в 2008 году вышла платная версия продукта. Также существует и бесплатная «домашняя» версия, ограничивается использованием в домашней сети. Её мы и будем использовать в наших целях.

Мы начинаем цикл обучающих статей, посвященных взаимодействию сканеров уязвимостей с Метасплоитом.

Требуемое программное обеспечение: Kali Linux.
Необходимые знания: опыт работы с консолью Linux-систем (в частности, дистрибутивом Kali Linux) и консолью Метасплойта.

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

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

Как известно, Metasploit Framework – это инструмент для создания, тестирования и использования эксплойтов. Но, благодаря поддержки модулей и плагинов, он вполне может сгодиться и для поиска уязвимостей.

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

Существует несколько популярных securty дистрибутивов, содержащих большинство популярных утилит и приложений для проведения тестирования на проникновение. Обычно они основаны на существующих Linux-дистрибутивах и представляют из себя их переработанные версии. В этой статье будут представлены наиболее известные из них.

При проведении тестирования на проникновение необходимо агрегировать данные из нескольких источников и проводить сравнение результатов периодических тестов. Для этой цели служат специализированные фреймворки, которые будут рассмотрены в этой статье.

Введение

Возможно некоторые читатели помнят мою самую первую статью на ресурсе, посвященную загрузке Windows с VHD-образа. Возможно я бы и не вернулся к этой теме, если бы не нашлись люди, попытавшиеся повторить данную технологию на своих домашних машинах. Естественно, с реализацией этого решения возникли проблемы, касающиеся в основном тех ошибок, которые выплевывает bootmgr в тех случаях, когда ему что либо не нравится. Попытки интерпретации ошибок загрузки вроде 0xc03a0003 путем гугления к особо ценным результатам не приводят, а документация Microsoft на этот счет хранит многозначительное молчание. Возникла идея изучить процесс обработки VHD-образов, получив информацию из первых рук, то есть от самого загрузчика.

Если обратится к уже имеющейся в сети информации, то существует замечательный блог "Записки эникейщика о Windows" на страницах которого (раз, два и три) размещены, на мой взгляд, самые ценные сведения, по вопросам устройства bootmgr. Автор подробно рассмотрел процесс загрузки, включая исследования кода MBR и PBR, остановившись на структуре bootmbr, кратко описав происходящие при его работе процессы.

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

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

Я искал self-hosted мониторинговое решение с открытым кодом, которое может предоставить хранилище метрик, визуализацию и оповещение для физических серверов, виртуальных машин, контейнеров и сервисов, действующих внутри контейнеров. Опробовав Elastic Beats, Graphite и Prometheus, я остановился на Prometheus. В первую очередь меня привлекли поддержка многомерных метрик и несложный в овладении язык запросов. Возможность использования одного и того же языка для графических изображений и уведомления сильно упрощает задачу мониторинга. Prometheus осуществляет тестирование по методу как черного, так и белого ящика, это означает, что вы можете тестировать инфраструктуру, а также контролировать внутреннее состояние своих приложений.

В последнее время я вижу, как довольно большое количество людей применяет контейнерную виртуализацию только для того, чтобы запереть потенциально небезопасное приложение внутри контейнера. Как правило, используют для этого Docker из-за его распространенности, и не знают ничего лучше. Действительно, многие демоны первоначально запускаются от имени root, а далее либо понижают свои привилегии, либо master-процесс порождает обрабатывающие процессы с пониженными привилегиями. А есть и такие, которые работают исключительно от root. Если в демоне обнаружат уязвимость, которая позволяет получить доступ с максимальными привилегиями, будет не очень приятно обнаружить злоумышленников, уже успевших скачать все данные и оставить вирусов.
Контейнеризация, предоставляемая Docker и другим подобным ПО, действительно спасает от этой проблемы, но также и привносит новые: необходимо создавать контейнер для каждого демона, заботиться о сохранности измененных файлов, обновлять базовый образ, да и сами контейнеры часто основаны на разных ОС, которые необходимо хранить на диске, хотя они вам, в общем-то, и не особо нужны. Что делать, если вам не нужны контейнеры как таковые, в Docker Hub приложение собрано не так, как нужно вам, да и версия устарела, SELinux и AppArmor кажутся вам слишком сложными, а вам бы хотелось запускать его в вашем окружении, но используя такую же изоляцию, которую использует Docker?

Capabilities

В чем отличие обычного пользователя от root? Почему root может управлять сетью, загружать модули ядра, монтировать файловые системы, убивать процессы любых пользователей, а обычный пользователь лишен таких возможностей? Все дело в capabilities — средстве для управления привилегиями. Все эти привилегии даются пользователю с UID 0 (т.е. root) по умолчанию, а у обычного пользователя нет ни одного из них. Привилегии можно как дать, так и отобрать. Так, например, привычная команда ping требует создания RAW-сокета, что невозможно сделать от имени обычного пользователя. Исторически, на ping ставили SUID-флаг, который просто запускал программу от имени суперпользователя, но сейчас все современные дистрибутивы выставляют CAP_NET_RAW capability, которая позволяет запускать ping из-под любого аккаунта.
Получить список установленных capabilities файла можно командой getcap из состава libcap.

% getcap $(which ping)
/usr/bin/ping = cap_net_raw+ep

Флаг p здесь означает permitted, т.е. у приложения есть возможность использовать заданную capability, e значит effective — приложение будет ее использовать, и есть еще флаг i — inheritable, что дает возможность сохранять список capabilities при вызове функции execve().
Capabilities можно задать как на уровне ФС, так и просто у отдельного потока программы. Получить capability, которая не была доступна с момента запуска, нельзя, т.е. привилегии можно только понижать, но не повышать.
Также существуют биты безопасности (Secure Bits), их три: KEEP_CAPS позволяет сохранить capability при вызове setuid, NO_SETUID_FIXUP отключает перенастройку capability при вызове setuid, и NOROOT запрещает выдачу дополнительных привилегий при запуске suid-программ.

Немного предыстории

Мобильное приложение Badoo существует для основных «нативных» платформ (Android, iOS и Windows Phone) и для мобильного веба. Несмотря на то, что в разработке мы не используем никаких кроссплатформенных фрэймворков, подавляющая часть бизнес-логики в приложениях схожа, и чтобы не дублировать функциональные тесты для всех платформ, мы пишем кроссплатформенные тесты с помощью Cucumber, Calabash и Appium. Это позволяет нам выносить в общую часть и переиспользовать в тестах для всех платформ код, отвечающий за проверку этой самой бизнес-логики. Различной же остается лишь реализация взаимодействия с приложением (более подробно мы рассказывали об этом здесь).

Когда кроссплатформенная автоматизация только начиналась (на iOS и Android), было принято решение использовать в качестве серверов Mac Mini. Это позволило сделать каждую из 8 билд-машин универсальной: на ней можно было собирать и запускать функциональные и юнит-тесты как для приложений на iOS, так и на Android. Такое решение устраивало нас практически всем до тех пор, пока количество функциональных тестов не перевалило за пять сотен для каждой платформы, а прогоны не стали требовать все больше времени. Для того чтобы удержать время прогона в разумных границах, мы постоянно работаем над оптимизацией тестов, а также добавляем новые Android-устройства (для iOS мы добавляем симуляторы по-другому). Со временем у нас появились Mac Mini с более чем 8 смартфонами. Важно отметить, что мы подключаем устройства одной модели к одному серверу, чтобы прогоны тестов были консистентны на одном агенте.

Docker за последнее время стал очень популярен за счет своей производительности, отказоустойчивости и, главное, простоты.

Сегодня можно найти тысячи образов в hub.docker.com. За счет своей простоты в создании образов, буквально за пол часа можно начать вносить свой вклад.

Но многие забывают о best practices, и за счет этого docker hub наполнился огромным количеством не самых лучших образов.

В этой статье я хочу описать на сколько просто и полезно создавать образы используя Best Practices на примере.

Появилась необходимость создать облачный сервис и для реализации этого проекта было выбрано open source решение OpenShift. После успешного прохождения Getting Started и деплоя HelloWorld, возникли неожиданные трудности: официальная документация потребовала детального изучения для решения такой простой задачи, как поднять свой готовый контейнер, с произвольным содержанием. Пришлось немного разобраться и ниже простое готовое руководство. Подразумевается, что читатель знаком с docker, т.к. объяснений его команд в данном мануале нет.

Сегодня, после обновления на Docker 1.9 у меня вполне ожидаемо сломался ранее прекрасной работающий Weave.
Описание возникших проблем и их решение под катом.

Docker — технология, вокруг которой нынче огромное количество хайпа. «Shitstorm» — именно таким словом окрестил в твиттере докеровые войны один из моих немецких знакомых. Ну и конечно, вместе с «Microservices» и «Reactive», слово «Docker» прочно вошло в тройку ведущих айтишных баззвордов последних двух лет.

Неделю назад на московской встрече CodeFreeze Александр aatarasoff Тарасов из Альфа-Лаборатории (подразделение Альфа-банка) рассказал от том, как они внедряли у себя Docker, какой получили профит, какую боль и т.п. Интрига в том, что, с одной стороны, Альфа-банк — это банк, то есть, «кровавый энтерпрайз». С другой стороны… внедрили же.



Под катом — короткое описание того, о чем рассказал нам Александр и видеозапись его выступления.

Ниже описано как запускать Keystone тесты в Docker контейнере на OS X и зачем это мне понадобилось.



Я иногда пишу небольшие патчи в Openstack, в основном в Keystone. Делаю это на моем лаптопе с OS X. В 2009 я перешел с Linux на Mac, т.к. на последнем разрабатывать было не менее удобно, а заниматься всем остальным — гораздо удобнее. К сожалению, последнее время первое утверждение часто оказывается ложным. Например, Apple начала очень медленно обновлять системные open source библиотеки, от чего пострадали тесты Keystone — сначала из-за старого OpenSSL, а потом и python-ldap. Об этом, например, пишет Keystone PTL Morgan Fainberg. Начинает он оптимистичным

NOTICE: OS X based testing/running of Keystone will likely be deprecated

Можно с этим бороться, но удовольствие уже не то.

Те, кто любит устройства от Synology и отличный сервис резервного копирования CrashPlan уже много лет кувыркаются, пытаясь настроить его надежную и бесперебойную работу на хранилище. С приходом Docker на Synology появился свет в конце тоннеля.

Под катом расскажу как я усовершенствовал автоматическое создание и разворачивание окружения для веб-разработки на основе Docker, Fig, DNSMasq и nsenter. По сути, это разворачивание LAMP сервера и запись о нем в DNSMasq, но приоритетами являются незасоренность хост-машины ненужным софтом типа web-, db-серверов на хост машине и минимальное количество команд для запуска

Совсем недавно, после выхода Compose 1.6.0+ и Docker 1.10.0+, стала доступна 2 версия.
Добавлены ключи: services, volumes, networks. Будут удалены ключи: links.

Эта статья описывает использование контейнеров docker как отдельные ноды для системы непрерывной интеграции, в данном случае jenkins. Кому лень читать tl; dr
Для сборки нашего проекта в RPM и DEB пакеты мы используем Jenkins, на что выделена специальная машина.

Сначала мы собирали наш проект только для CentOS 6. Далее добавилась поддержка CentOS 5, и оказалось что зависимости от конкретных версий библиотек не дают работать тем же бинарникам под разными версиями CentOS, понадобилась сборка разных RPM. Это было решено добавлением в jenkins ноды с CentOS 5, которой служила виртуалка на VirtualBox. Потом добавилась поддержка Suse, а потом и Debian.

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