пятница, 9 мая 2014 г.

Краудфандинг проекта OpenVZ - создадим виртуализацию нашей мечты! :)

Всем привет!

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

Например, у нас, есть вот такие инфраструктурные хотелки как:
1) UUID вместо CTID
2) Хранение конфигов контейнеров в папке /vz для унификации и удобства поддержки
3) Поддержка монтирования нескольких отдельных ploop образов к одному контейнеру
4) Эффективно работающий pcompact
5) Вложенные Kernel namespaces внутри контейнера
6) Запуск vzctl хуков в контексте физического сервера, а не контейнера

У авторов OpenVZ, компании Parallels нет супер активных планов по развитию проекта OpenVZ (кроме, разумеется, развития ядра). Но у них есть потрясающая возможность - OpenVZ Maintenance Partnership, через которую Вы можете получить решение Ваших багов, а также запросить "расчет" стоимости той или ной фичи: https://openvz.org/Support

Цены на фичи - информация секретная, но я могу четко сказать, что в зависимости от сложности "фичи" они варьируются от нескольких тысяч до десятков тысяч долларов.

Конечно же, для одной компании - это крупные деньги да и за многие "мелкие фичи" их попросту жалко.

Но тут на помощь нам приходит Интернет с его супервозможностями, а именно - краудфандинг!

Я предлагаю собрать набор функций, в которых есть потребность у сообщества и начать сбор средств на их реализацию.

Если у кого есть интерес - приглашаю к обсуждению (предпочтительно почтой) - мои контакты справа :)

Даже если Вы не согласны помогать финансово, то все равно пишите - помощь даже на уровне сбора функций и определения будущего проекта, которое интересно именно кастомерам - бесценна!

Спасибо :)

четверг, 8 мая 2014 г.

Верите в эффективность антивирусов для обнаружения зловредного ПО на Linux? Напрасно! Разгромный отчет-тест :)

Прошу к ознакомлению, какой антивирус лучший из худших! Ссылка

Как полностью скачать WIki GitHub проекта

 git clone git@github.com:юзернейм/имя_проекта.wiki.git

Какие книги читать, чтобы отлично знать Linux?

Конкретно для системных администраторов таких книг нету. Но я искренее убежден, что ЛЮБОЙ системный администратор ОБЯЗАН хотя бы базово знать язык С, ибо без него в Linux/Unix не ступить ни шагу и никогда не понять эти ОС полностью.


Linux. Руководство программиста - Дж. Фуско: http://www.ozon.ru/context/detail/id/5560388/
Linux. Программирование в примерах Арнольд Роббинс: http://www.ozon.ru/context/detail/id/3935922/

Более серьезные книги:
Ядро Linux. Описание процесса разработки: http://www.ozon.ru/context/detail/id/17925734/

Поиск зловредного ПО и аномалий на сильно нагруженных Linux серверах

Всем привет :)

Презентую небольшой тулкит - Antidoto, для поиска аномалий на Linux серверах.

Что он умеет?
  • Сообщать об удаленных файлах с информацией о дате последнего логина: /var/log/btmp, /var/log/wtmp
  • Сообщать о наличии crontab файлов (/var/spool/cron/crontabs, /var/spool/cron) для пользователей apache, www-data
  • Сообщать о не пустых файлах и папках со странными именами в папках /tmp и /var/tmp
  • Сообщать о процессах запущенных по относительному пути (./programm_name) не от root пользователя
  • Сообщать о процессах, исполняемый файл которых был удален после запуска приложения
  • Определять особо популярную у нас заразу по md5 (база в 10 вирусов вшита в код)
  • Cообщать об опасных прослушиваемых udp, tcp портах (irc, proxy, botnet controllers)
  • Cообщать об опасных udp, tcp подключениях к удаленным машинам (irc, botnet controllers)
  • Cообщать о процессах с архитектурой отличной от архитектуры машины - например, 32 битное ПО на 64 битном серверве
  • Сообщать о процессах, исполняемые файлы которых являются статически слинкованными файлами (с интегрированными библиотеками)
  • Сообщать о процессах, которые были запущены с использованием директивы LD_PRELOAD (подключение библиотек к ПО без линковки)
  • Сообщать о процессах, бинарные файлы которых имеют флаги SGID или SUID
  • Уведомлять о клиентских соединениях на удаленные сервера в более чем 5 потоков на 1 процесс на 1 удаленный порт

Новай пакет по диагностике серверов - sys-dig

Всем крайне рекомендую к ознакомлению: http://www.sysdig.org/ :)

Внимание! Если Вы используете OpenVZ, то эта программа может повесить Ваш сервер! К счастью, баг уже исправлен разработчиками, разве что нужно собрать дравйер из репо:

cd /usr/src
git clone https://github.com/draios/sysdig.git
cd driver
cmake .
make
insmod sysdig-probe.ko
Это очень мощный инструмент, в чем Вы можете убедиться вот здесь: https://github.com/draios/sysdig/wiki/Sysdig%20Examples

Не верите?

А вот такой способ:
sysdig -c fdbytes_by fd.cip

Сделать выбор top IP адресов клиентов сервера на основе числа переданных байт! Потрясающе!

понедельник, 5 мая 2014 г.

Почему Вы неверно ищете вирусы через Maldet и ClamAV?

Предлагаю к ознакомлению:  ссылка

Суть статьи простая - подключайте базы Maldet в обязательном порядке! 

Производительность ClamAV и его корректное использование

Статья опубликована на GutHub, здесь оставляю лишь ссылку и выводы:  ссылка

Итоги:
Параллельное сканирование через демона ClamAV: 34.176 sec
Однопоточное сканирование через демона ClamAV: 191.848 sec
Сканирование через ClamScan: 215.018 sec

AuthBind: Разрешает не-root программам быть назначенными младшим портам

Тотально полезная штука (особенно в случае bad architecture by design): https://packages.debian.org/wheezy/authbind

Но иногда оно правда бывает полезным.

воскресенье, 4 мая 2014 г.

Почему контейнеры - это очень сложно управляемая технология для системного администратора?

Сейчас контейнеры - настоящий тренд в Linux ядре и современных дистрибутивах. Но почему-то при активном развитии ядра все забывают о user space, что приводит к очень большим проблемам при эксплутации контейнеризации.

Все ниже сказанное про актуальные версии утилит в CentOS 6 и репозитории Epel в контексте технологии OpenVZ.

* netstat: не имеет возможности изоляции, а также не представляет возможности посмотреть соединения только HWN 0 (физического сервера)
* lsof: его использование на OpenVZ почти невозможно из-за сотен и тысяч ошибок вида: lsof: no pwd entry for UID 33
* iotop: не имеет поддержки отображения дисковой нагрузки от отдельных контейнеров
* top: не имеет поддержки как отображения CTID, так и отображения нагрузки в контейнере
* ps: не имеет стандартной возможности фильтрации по CTID, не имеет возможности отображать только процессы виртуальной машины
* htop: имеет (!) поддержку отображения CTID процессов, но не умеет отображать нагрузку из виртуальных окружений
* ipcs: возможности просмотра IPC ресурсов конкретного контейнера нет, стандартно отображаются только ресурсы ноды

Что делать системным администраторам? В общем-то выбор невелик - писать многочисленные обвязки в стиле: https://gist.github.com/pavel-odintsov/3e7351ba4ceca33b8cc6

Почему такая ситуация ОЧЕНЬ ОПАСНА? А Вы попробуйте просмотреть слушающие (LISTEN) соединения на аппаратной ноде OpenVZ. Это просто рай для руткитов, там слона можно спрятать, так как возможности просмотреть все соединения _именно ноды_ тупо не существует без собственного ПО.

Ранее в проекте OpenVZ были утилиты vzps и vztop (тыц, тыц), которые работали просто замечательно (на CentOS 5) и выручали много раз, но в CentOS 6 их развитие было прекращено, а в связи с тем, что их код закрыт - нет возможности их портировать на CentOS 6 хотя бы вручную.

суббота, 3 мая 2014 г.

Как выдернуть исходный код из запущенного Perl скрипта?

Запускаем: gdb после этого подключаемся к Pid процесса, который нас интересует:  attach 1708

Генерируем core dump: generate-core-file

А далее ничего умнее чем прогнать strings в голову не приходит =( Но в моем случае это помогло и пароли нашлись на ура!

Еще инфа: http://stackoverflow.com/questions/3576710/reverse-engineering-a-perl-script-based-on-a-core-dump


пятница, 2 мая 2014 г.

Тест: Насколько Вы крутой Linux инженер?

Задачка!

Задача является хитрым продолжением таски вида:

У вас есть запущенное приложение, исполняемый файл которого удален - как его восстановить?

Ее решение весьма тривиальное и даже могу его озвучить:
cp /proc/$pid/exe /root/rescued_file
Либо если речь идет о файле, открытом приложением на запись:
cp /proc/$pid/fd/X /root/rescued_file

Моя задача на порядки сложнее.

Итак, есть некое приложение, пусть это будет /usr/bin/host, которое было запущено с библиотекой libworker.so через LD_PRELOAD следующим образом:
LD_PRELOAD=/somepath/libworker.so /usr/bin/host.

Договоримся о том, что в библиотеке libworker крутится внешний цикл и пока приложение с этой библиотекой (/usr/bin/host) не будет убито - оно будет висеть в памяти.

А теперь самое интересное - удаляем библиотеку libworker с диска.

Теперь псевдофайл /proc/$pid/smaps примет вот такой вид (привожу лишь выдержку):
7fc51b53f000-7fc51b540000 rw-p 00006000 b6:ff161 30664                    (deleted)/somepath/libworker.so
Size:                  4 kB
Rss:                   4 kB
Pss:                   4 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         4 kB
Referenced:            4 kB
Anonymous:             4 kB
AnonHugePages:         0 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Как видите, мы видим номер inode, принадлежащий данной библиотеке, видим ее имя, но с диска она удалена и возможности ее прочесть нету. В открытых файловых дескрипторах (/proc/$pid/fd) она также не значится.

Есть путь в лоб - использование debugfs и посмотреть содержимое файла из внутренностей ext3/ext4. Но в случае высокой нагрузки и отсутствия настолько высокого уровня доступа - это решение неосуществимо.

Итак, как извлечь удаленную библиотеку из памяти? :)