Рубрика: monitoring

Wireshark — как это работает?

Wireshark — это достаточно известный инструмент для захвата и анализа сетевого трафика, фактически стандарт как для образования, так и для траблшутинга.
Wireshark работает с подавляющим большинством известных протоколов, имеет понятный и логичный графический интерфейс на основе GTK+ и мощнейшую систему фильтров.
Кроссплатформенный, работает в таких ОС как Linux, Solaris, FreeBSD, NetBSD, OpenBSD, Mac OS X, и, естественно, Windows. Распространяется под лицензией GNU GPL v2. Доступен бесплатно на сайте wireshark.org.
Установка в системе Windows тривиальна — next, next, next.
Самая свежая на момент написания статьи версия – 1.10.3, она и будет участвовать в обзоре.

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

Начинаем

Для начала захвата достаточно выбрать свой сетевой интерфейс и нажать Start.

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

А следующая за ними кнопка позволяет сделать быстрый переход к пакету, указав его номер.
В случае если колонки перекрываются и наползают друг на друга, можно кликнуть по такой колонке правой кнопкой мыши и выбрать “Resize Column”.
Произойдет автоматическая подгонка размеров под текущую ситуацию.
И кроме того, есть кнопка “Resize all Columns”, которая приведет в порядок все колонки.
Используя меню View – Time Display Format, можно, например, настроить, чтобы отсчет времени шел не с начала захвата, а с момента получения предыдущего пакета (Since Previous Captured Packet).
Самое важное в каждой программе (Help – About Wireshark) покажет не только версию и список авторов, но и содержит закладку Folders, которая покажет пути размещения каталогов с конфигурациями.
Изучая интерфейс, можно выбрать, например, пакет http, и увидеть, что HTTP инкапсулируется в TCP (транспортный уровень), TCP инкапсулируется в IP (сетевой уровень), а IP в свою очередь инкапсулируется в Ethernet (перед этим даже мелькает 802.1Q).

И на самом верху идет нечто вроде небольшого обзора собранной информации о кадре.

Про фильтры мы поговорим дальше, а на данном этапе, если нужно быстро отфильтровать лишние пакеты, достаточно сделать правый клик на пакете, выбрать меню Apply as Filter – Not selected и изменения сразу же вступят в силу.
Если нужно еще что-то убрать, то в следующий раз выбирать “and not Selected”, и новое правило просто добавится к фильтру.

Убираем заусенцы

Довольно часто при работе с Wireshark возникает ошибка IP checksum offload – ошибка контрольной суммы заголовка IP пакета.

Современные сетевые карты насколько умные, что сами считают контрольную сумму, зачем это делать на уровне стека TCP/IP программно, если можно делать хардварно.
А Wireshark натурально перехватывает пакеты, до того как они попадают в сеть.
И до того как эта сумма была просчитана и была добавлена в заголовок пакета.
Соответственно есть два пути решения этой проблемы — выключать функцию offload в настройках сетевой карты или в настройках сниффера указать, чтобы он не обращал внимание на это значение.
Хардваные функции зачастую лучше софтварных, в основном из-за скорости обработки (в железе обычно выше) поэтому лучше изменить настройки самого сниффера.
Для этого нужно зайти в настройки (Edit — Preferences), затем Protocols – IPv4 – и снять флаг с “Validate IPv4 checksum if possible”.

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

  • Локально на своем хосте;
  • Организовать зеркалирование трафика на коммутаторе;
  • Подключаться непосредственно в интересующие места;
  • или же отравление протокола ARP (еще более незаконно, чем пассивное прослушивание трафика)

 

Фильтруем поток

Wireshark содержит два вида фильтров – захвата (Capture Filters) и отображения (Display Filters).
Вначале рассмотрим Capture Filters.
Как можно догадаться по названию, они служат для фильтрации еще на этапе захвата трафика.
Но в таком случае, безусловно, можно безвозвратно потерять часть нужного трафика.
Фильтр представляет собой выражение, состоящее из встроенных значений, которые при необходимости могут объединяться логическими функциями (and, or, not).
Для того, чтобы его задействовать, нужно зайти в меню Сapture, затем Options, и в поле Capture Filter набрать, например, host 8.8.8.8 (или, например, net 192.168.0.0./24)

Так же, конечно, можно выбрать и заранее созданный фильтр (за это отвечает кнопка Capture Filter).
В любом из вариантов фильтр появится возле интерфейса, можно жать Start.

Теперь перейдем к Display Filters.
Они фильтруют исключительно уже захваченный трафик.
Что можно фильтровать?
— Практически все — протоколы, адреса, специфические поля в протоколах.
Операции, которые можно использовать при построении фильтров:

Команда Значение Пример использования
== равенство ip.dst == 193.168.3.10
!= Не равно udp.dst != 53
< меньше чем ip.ttl < 24
> больше чем frame.len > 10
<= меньше или равно frame.len <= 0x20
>= больше или равно tcp.analysis.bytes_in_flight >= 1000
matches регулярные выражения frame matches «[Pp][Aa][Ss][Ss]»
contains содержит dns.resp.name contains google

Как вы, наверное, заметили, в таблице в качестве примеров были разнообразные выражения, достаточно понятные и зачастую говорящие сами за себя.
Например, ip.dst – это поле протокола IP.
Чтобы увидеть это поле, можно просто посмотреть на пакет, и в нижней части окна можно увидеть его значение, которое потом можно применять в любом фильтре.
Например, нас интересует, как создать фильтр, где будет проверяться значение TTL.
Для этого раскрываем L3 часть и становимся на соответствующее поле:

И видим, что для построения фильтра, нужно использовать выражение ip.ttl.
Если начать набирать фильтр, то после точки автоматически появится список возможных значений:

Чтобы применить фильтр, достаточно нажать enter или кнопку Apply.
Само поле для ввода фильтра может менять цвет в зависимости от того, что было набрано.
Зеленый цвет означает, что все в порядке. Красный — допущена ошибка, желтый — получен неожиданный результат, потому что существуют другие варианты написания фильтра (например можно написать ip.dst != 8.8.8.8 или же !ip.dst == 8.8.8.8, именно второй вариант более предпочтительный).
Фильтры можно сохранять для дальнейшего использования, нажав кнопку Save, затем ввести произвольное название

и после нажатия на кнопку ОК фильтр появится как кнопка на панели.

А если кликнуть на расположенную неподалеку кнопку «Expression…», то откроется достаточно мощный конструктор выражений, по которому можно чуть ли не изучать сетевые протоколы. Количество поддерживаемых протоколов постоянно увеличивается.

Как уже упоминалось ранее, можно выделить любой пакет и в контекстном меню выбрать Apply as Filter и в подменю выбрать режим — selected или not selected и соответственно сразу же появится фильтр, который будет показывать только выбранное или наоборот уберет выбранное с экрана.
Таким образом можно гибко выбирать, что видеть на экране, а что — нет.
Это может быть определенный ip-адрес, ttl, порт, dns ответ и многое другое.
Кроме того, есть два варианта для таких быстрых фильтров — Prepare as Filter и Apply as Filter.
Как можно догадаться по названию — разница заключается в том, что в первом случае только появится в поле для ввода Display Filter, но не применится (удобно, если например, добавлять таким способом несколько фильтров, а затем сразу применить готовый результат), а во втором — сразу же и применится.

Фильтры можно объединять, используя знакомые по булевой алгебре логические операции:
(dns) && (http) логическое и

(dns) || (http) это логическое или

Таким образом можно строить большие и сложные фильтры вроде:
(tcp.flags.syn==1) && (ip.src == 172.16.10.2) && (ip.dst == 172.16.10.1)
Здесь видим, что выбираются только TCP SYN сегменты, только с определенным адресом отправителя и получателя. При составлении больших фильтров нужно помнить, что фильтр по сути — логическое выражение, и если оно истинно, то пакет отобразится на экране, если ложно — нет.

Ныряем глубже

Достаточно частая ситуация, когда возникают жалобы на медленную работу сети, причин этого может быть множество.
Попробуем разобраться, в чем может быть причина, и рассмотрим два способа.
Первый состоит в добавлении колонки TCP delta.
Открываем пакет, находим поле Time since previous frame in this TCP frame, правый клик и выбираем Apply as Column. Появится новая колонка.
На ней можно кликнуть правой кнопкой мыши и выбрать режим сортировки, например, Sort Descending.

И сразу же рассмотрим второй способ.
Относительно недавно (в версии 1.10.0) появился фильтр tcp.time_delta, который, собственно, учитывает время с момента последнего запроса.

Если клиент делает запрос и получает ответ через 10 миллисекунд, и клиент говорит, что у него все медленно работает, то, возможно, проблема у самого клиента.
Если же клиент делает запрос и получает ответ через 2-3 секунды, тут уже, возможно, проблема кроется в сети.

Еще глубже

Если посмотреть в TCP пакет (или сегмент если быть точным), то можно увидеть там Stream index, который начинается обычно с нуля.
Само поле будет называться tcp.stream.

По нему можно сделать правый клик и создать фильтр.

Таким образом можно фильтровать нужные соединения.

Еще один способ – сделать правый клик на самом пакете, выбрать Conversation Filter и создать фильтр для l2 l3 l4 уровня соответственно.

В итоге мы опять увидим взаимодействие двух хостов.

И третий вариант — это одна из самых интересных фич — Follow TCP Stream.
Для того чтобы его задействовать, нужно опять таки кликнуть правой кнопкой мыши на пакете и выбрать “Follow TCP Stream”. Появится окно, где будет наглядно продемонстрирован весь обмен между двумя узлами.

Если же зайти в меню Statistics – Conversations, то, выбирая закладки, можно увидеть статистику по таким “разговорам” и различные сессии, при этом можно отсортировать их по различным колонкам, например, по количеству переданных данных.

И прямо в этом окне можно правой кнопкой взывать контекстное меню и опять же применить как фильтр.

Со временем приходит опыт

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

Нажатие на эту кнопку приведет к открытию окна Expert Infos.
Того же результата можно добиться, пройдя в меню Analyze – Expert Info.

В этом окне будет содержаться информация по найденным пакетам, разбитая на группы Errors, Warnings, Notes и Chats.
Цветовая раскраска для этих групп выглядит следующим образом:
Ошибки — красный цвет
Предупреждения — желтый
Примечания — сине-зелёный (cyan)
Чат — серый

Wireshark содержит в себе мощный анализатор и умеет автоматически обнаруживать большое количество проблем, возникающих в сети.
Как вы уже могли заметить, буквально везде можно использовать фильтры и Expert Info не является исключением.
Для того чтобы создать такой фильтр, нужно использовать конструкцию expert.severity.
Например, expert.severity==error.

Грабим трафик!

Можно ли с помощью Wireshark узнать, что было скачано?
Да, можно. И сейчас это увидим.
Вначале возьмем HTTP трафик.
Сделаем правый клик по HTTP пакету — Protocol Preferences – и видим тут массу опций, которые непосредственно влияют на извлечение файлов из веб трафика.
Для того чтобы увидеть, что можно извлечь из текущего дампа нужно перейти в меню File – Export Objects – HTTP.
Появится окно, которое покажет все захваченные http объекты — текстовые файлы, картинки и т.д. Для того чтобы вытащить любой файл из этого списка, достаточно просто выделить его и нажать Save As.

Как можно заметить, рисунок был извлечен без каких-либо проблем.

Таким же способом, можно извлекать и потоковое видео/аудио.

Но на этом возможности Wireshark не заканчиваются!
Он умеет вытаскивать файлы и с протокола FTP.
Для этого можно использовать знакомый уже Follow TCP Stream.
В итоге отобразится только обмен по протоколу FTP, в котором нужно будет найти строку RETR, что собственно и будет означать передачу файла.

Затем опускаемся дальше, находим пакеты уже непосредственно с файлом (FTP-DATA) и опять выбираем Follow TCP Stream, видим содержимое файла, жмем Save As и сохраняем.

VoIP

Wireshark имеет несколько встроенных функций для работы с этой технологией.
Он поддерживает массу голосовых протоколов — SIP, SDP, RTSP, H.323, RTCP, SRTP и другие.
И, конечно же, умеет перехватывать и сохранять голосовой трафик для дальнейшего прослушивания.
Этот функционал как нельзя лучше подойдет для траблшутинга в сетях Voice over IP.
Меню Statistics — Flow Graph покажет наглядную картину, как происходил весь обмен пакетами.

А вообще целое меню Telephony отведено для работы с голосовым трафиком.
Например, Telephony – RTP – Show All Streams покажет подробно, что происходило с RTP, в частности jitter (параметр, который, вероятно, самый важный в голосе), что иногда сразу скажет о наличии проблем.

Нажав на кнопку “Analyze”, можно открыть окно RTP stream Analysis – и, выбрав там поток, можно его даже проиграть, используя кнопку player.
Сначала отроется окно проигрывателя, в котором вначале нужно установить подходящее значение jitter и использовать кнопку decode.

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

Так же существует еще один способ прослушивания голосовых звонков — можно зайти в меню Telephony – VoIP Calls.

Откроется окно со списком совершенных звонков, где опять же можно нажать кнопку player, отменить нужные разговоры флажками и нажать play.
Для того чтобы добиться приемлемого качества звучания, потребуется проиграться со значением поля jitter buffer, меняя его значение.

Небольшое отступление

Некоторое время назад появился сайт CloudShark.org.

Это тот самый сниффер Wireshark, но реализованный в виде онлайн-сервиса. Очевидно, что с его помощью не удастся захватывать сетевой трафик, но выполнять анализ дампа трафика – вполне. Загрузив туда через форму PCAP-файл на анализ, можно будет получить четкую последовательность пакетов, в которой всё данные будут разбиты на понятные поля в зависимости от протокола. В общем, тот же Wireshark, но немного облегченный и доступный из любого браузера.

Финальная битва

Напоследок рассмотрим как выглядит сканирование портов.
Смотрим на дамп и видим, что вначале происходит ARP запрос и затем непосредственно начинается сканирование. Адрес нашего маршрутизатора 192.168.10.11, сканирование идет с адреса 192.168.10.101

Это, так называемое, SYN сканирование, когда идут SYN-пакеты на указанный диапазон портов. Так как большинство портов закрыто, маршрутизатор отвечает пакетами RST, ACK.
Пролистав чуть ниже видим, что открыт telnet (tcp 23).

На это указывает то, что маршрутизатор ответил пакетом SYN, ACK.
К слову, для фильтрации портов в сниффере можно использовать конструкции вида: tcp.srcport, tcp.dstport и tcp.port. Для протокола UDP всё аналогично — udp.srcport, udp.dstport, udp.port.

Удаленный контроль

Управляем удаленной машиной с помощью Google Talk, Twitter, Dropbox и Google+

Сегодня социальные сервисы окружают нас со всех сторон. Мы чатимся в Jabber, читаем новости в Twitter, выкладываем фотки в Google+. Мы делаем это с домашних компов, смартфонов и планшетов ежедневно в почти автоматическом режиме. Для многих из нас Twitter или Facebook давно стал заменой электронной почты и IRC-чатов. Так почему бы не использовать те же сервисы для мониторинга удаленной машины и даже управления ей?

Постановка задачи

В этой статье мы рассмотрим несколько интересных приемов, с помощью которых можно настроить:

  • Мониторинг удаленной машины средствами Twitter. Мы создадим специального твиттер-юзера, от лица которого наш сервер/медиацентр/ПК будет слать сообщения о своем состоянии, мы сможем читать их через веб или с помощью твиттер-клиента.
  • Управление через Jabber. Мы сделаем Jabber-бот, который будет выступать посредником между нами и консолью удаленной машины. Все написанные ему сообщения будут интерпретироваться как консольные команды, ответ на которые будет выслан в ответном сообщении.
  • Управление через Dropbox. Мы создадим простой демон, который будет выполнять команды по мере их появления в указанном файле внутри диска Dropbox.
  • Камеру слежения с отчетом в Google+. Мы сделаем простой бот, который будет выкладывать в Google+ фотографии, сделанные веб-камерой. Так мы сможем следить за чем угодно удаленно без необходимости организовывать специальный сервис.
  • Видео по запросу. Мы сделаем бот, который будет по нашему запросу снимать видео определенной длительности, а затем выкладывать его в наш приватный канал YouTube.

Все это делается Just for fun, поэтому я заранее соглашусь с теми, кто скажет, что подобные вещи нужно делать с помощью SSH и специальных веб-панелей управления. В то же время хочу заметить, что некоторые из приведенных приемов могут быть удобнее классических подходов. Но обо всем, как обычно, по порядку.

Twitter и отчеты о состоянии

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

Как это сделать? Для этого понадобятся: новый аккаунт в Твиттере, консольный твиттер-клиент и простой скрипт, который будет генерировать нужные нам сводки информации. С первым все просто. Регистрируем новый e-mail, создаем аккаунт, делаем его приватным и добавляем свой основной аккаунт в список подписчиков. Таким образом доступ к информации о состоянии сервера сможешь получить только ты.

Далее нам понадобится клиент, с помощью которого мы будем отправлять отчеты. Популярный TTYtter справится с этой задачей на отлично. Устанавливаем:

$ sudo apt-get install ttytter

Запускаем клиент, видим сообщение, что необходимо получить OAuth-токен, соглашаемся нажатием . Видим на экране ссылку, открываем ее в браузере и нажимаем кнопку «Авторизовать». На экране появится PIN-код, который следует скопировать и ввести в ответ на приглашение TTYtter. Теперь можно отправить тестовый твит вот так:

$ echo "Привет из консоли!" | ttytter -script

А еще лучше так:

$ free | grep Mem | ttytter -script

Другими словами, теперь мы можем отправить вывод абсолютно любой команды на нашу страницу в твиттере, просто перенаправив ее вывод в TTYtter. Написав же небольшой скрипт и прописав его в расписание cron, мы можем сделать так, чтобы машина отправляла любую указанную информацию через определенные промежутки времени. Для примера возьмем следующий скрипт (фактически это сильно урезанная и доработанная версия скрипта, опубликованного в блоге fak3r.com):

$ vi ~/bin/twitter-monitor.sh #!/bin/bash # Формируем твит # Имя хоста HOST=`hostname -s` # Аптайм машины UP=`uptime | cut -d" " -f4,5 | cut -d"," -f1` # Средняя нагрузка LOAD=`uptime | cut -d":" -f5,6` # Скорость пинга PING=`ping -q -c 3 google.com | tail -n1 | cut -d"/" -f5 | cut -d"." -f1` # Количество занятой памяти MEM=`ps aux | awk '{ sum += $4 }; END { print sum }'` # Нагрузка на процессор CPU=`ps aux | awk '{ sum += $3 }; END { print sum }'` # Собираем инфу вместе TWEET="(HOST) ${HOST} (UP) ${UP} (CPU) ${CPU}% (MEM) ${MEM}% (LOAD) ${LOAD} (PING) ${PING}ms" # Отправляем твит echo $TWEET | ttytter -script

Он собирает такую информацию, как имя хоста, аптайм, пинг до гугла, количество памяти, нагрузка на процессор, и отправляет все это одним твитом. Скрипт больше подходит для мониторинга сервера, но ты можешь изменять его как вздумается, главное — проверить, чтобы в итоге вся инфа умещалась в 140 символов, что можно сделать, заменив последнюю команду скрипта на «echo $TWEET | wc -c» и запустив его.

Теперь осталось лишь добавить скрипт в crontab, чтобы он запускался, например, каждый час:

$ crontab -e 0 * * * * /путь/до/скрипта.sh

Сделать это необходимо от имени того пользователя, от которого ты получил токен для TTYtter.

Ответ от сервера
Ответ от сервера

Управление через Twitter

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

Последнее приватное сообщение с помощью TTYtter можно получить так:

$ echo "/dma +1" | ttytter -script [DM da0][ezobnin/Tue Mar 26 09:59:59 +0000 2013] test test

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

$ vi ~/bin/twitter-command.sh #!/bin/sh while true; do CMD=`echo "/dma +1" | ttytter -script | sed 's/[.*] //'` sh $CMD sleep 60 done

Это самый примитивный вариант решения проблемы, страдающий от двух недостатков: во-первых, скрипт не знает, выполнил ли он уже команду, и будет делать это при каждой итерации цикла, даже если новых сообщений не поступало; во-вторых, у скрипта нет обратной связи, что хоть и не очень полезно в случае с Twitter, но может быть хорошим дополнением. Поэтому мы доработаем скрипт до приемлемого состояния:

$ vi ~/bin/twitter-command.sh #!/usr/bin/bash # Имя твиттер-юзера для ответов USER="user" while true; do # Получаем личное сообщение (команду) CMD=`echo "/dma +1" | ttytter -script | sed 's/[.*] //' # Проверяем, выполняли ли такую команду в прошлый раз if [ $CMD != $OLD_CMD ]; then # Если нет — выполняем REPL=`$CMD` # и отправляем ответ команды юзеру echo "/dm $USER ${REPL:0:140}" | ttytter -script # Сохраняем команду, чтобы не выполнять ее снова CMD = $OLD_CMD fi # Спим минуту sleep 60 done

Этот скрипт ведет себя гораздо умнее. Он отправляет результат выполнения команды юзеру, автоматически сокращая его до 140 символов, и запоминает последнюю выполненную команду, чтобы не запускать ее снова. С другой стороны, при запуске скрипт все равно выполнит последнюю отправленную ему команду, но я не думаю, что в этом есть большая проблема.

Скрипт управления через Твиттер
Скрипт управления через Твиттер
TTYtter в интерактивном режиме
TTYtter в интерактивном режиме

Управление через Jabber/GTalk

Twitter может быть отличным инструментом для мониторинга машины, но использовать его для того, чтобы отдавать удаленные команды, довольно неудобно. Гораздо лучше для этого подходит Jabber, который изначально был придуман для ведения текстового диалога между двумя сторонами.

В Linux есть несколько инструментов, позволяющих отсылать и принимать Jabber-сообщения из консоли (например, CJC: cjc.jajcus.net), но для реализации нашей задачи гораздо лучше подойдет Ruby-библиотека xmpp4r-simple, позволяющая реализовать Jabber-клиент, написав буквально три строки. Библиотека есть в репозитории Ruby Gems, поэтому для ее установки, например, в Ubuntu следует набирать такие команды:

$ sudo apt-get install ruby $ sudo apt-get install rubygems $ gem install xmpp4r-simple $ gem install session

Чтобы убедиться в ее работоспособности, можно использовать такой скрипт:

$ vi send-message.rb #!/usr/bin/env ruby require 'rubygems' require 'xmpp4r-simple' jabber = Jabber::Simple.new('юзер@gmail.com', 'пароль') jabber.deliver("адресат@gmail.com", "Привет, Gmail!")

Для решения нашей задачи такой скрипт бесполезен, но, дописав в него каких-то десять строк, мы реализуем полноценный бот:

$ vi jabber-bot.rb #!/usr/bin/env ruby require 'rubygems' require 'xmpp4r-simple' require 'session' # Запускаем сеанс sh, в котором будет происходить выполнение команд @sh = Session::new # Коннектимся к Jabber-серверу bot = Jabber::Simple.new(логин@gmail.com, пароль) while true # Ожидаем сообщение bot.received_messages do |msg| # Проверяем, что сообщение пришло от юзер@gmail.com if msg && msg.from.to_s.include?(юзер@gmail.com) # Выполняем команды в сеансе sh stdout, stderr = @sh.execute(msg.body) if msg.body # Отправляем в ответном сообщении вывод команды bot.deliver(msg.from, "n" + stdout.chomp) unless stdout.empty? # Отправляем поток ошибок bot.deliver(msg.from, "n" + stderr.chomp) unless stderr.empty? end end

Приведенный бот прост, но отлично справляется со своей работой. Все, что нужно сделать, — это завести юзера для бота, прописать его логин и пароль, а также адрес своего основного Jabber-аккаунта в скрипт, затем запустить скрипт и написать на адрес бота нужную команду. Результат запуска придет в ответном сообщении. Это действительно удобно, особенно когда нет возможности или времени выполнять полноценный логин по SSH (например, с телефона).

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

Управление с помощью Dropbox

Ты можешь удивиться, но рулить машиной можно даже с помощью Dropbox. По сути, это такой же грязный хак, не претендующий на роль нормального решения, но даже он может быть полезен в определенных ситуациях. В основе его работы лежит идея записи команд в файл. Клиент создает текстовый файл внутри каталога Dropbox и помещает в него строку, содержащую команду. На стороне сервера работает скрипт, который в цикле проверяет существование файла и, если такой существует, выполняет содержащуюся в нем команду и записывает ответ в другой файл. Серверный скрипт выглядит следующим образом:

$ vi ~/Dropbox/server.sh #!/bin/bash # Входим в бесконечный цикл while true; do # Файл существует? if [ -f  input.txt ]; then # Читаем файл, выполняем команду и записываем ответ в другой файл OUTCOM=$(cat input.txt) $OUTCOM > output.txt # Удаляем входной файл rm input.txt > /dev/null 2>&1 else # Если файла нет, уходим в сон sleep 10 fi done

После запуска скрипта любой, кто подключит тот же том Dropbox (зайдет с того же аккаунта), сможет выполнить команду на сервере, просто записав ее в файл input.txt. Так, например, можно управлять серверной машиной через веб-интерфейс, со смартфона или любого устройства, на котором есть клиент Dropbox. Для удобства управления с другой Linux-машины можно использовать такой скрипт:

$ vi ~/Dropbox/client.sh #!/bin/bash # Создаем входной и выходной файлы touch input.txt touch output.txt # Читаем команду echo -n "Enter Command: " read INCOM # Записываем команду в файл и ждем, пока клиент ее не прочитает, сигналом о чем для нас станет удаление файла echo "$INCOM" > input.txt while [ -f input.txt ];do sleep 10 done # Выводим на экран ответ сервера cat output.txt

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

Автозагрузка фото с камеры в Picasa/Google+

Аккаунт Google сегодня есть у всех, а значит, есть доступ к Google+, Picasa и куче других полезных и не очень сервисов. Большинство из них можно заскриптовать с помощью утилиты командной строки GoogleCL, которая позволяет работать с такими сервисами, как Picasa, Календарь, Blogger, Контакты, Документы и YouTube прямо из командной строки. С помощью этого инструмента можно делать множество интересных вещей, однако я покажу только два его применения: автоматическая публикация фоток с веб-камеры в альбом Picasa (Google+) и снятие видео с той же камеры и публикация в YouTube по запросу.

Чтобы реализовать такое, понадобится сам GoogleCL, который есть в любом дистрибутиве, а также в репозитории Python:

$ sudo apt-get install googlecl $ sudo pip install googlecl

Далее мы должны создать новый альбом в Picasa, куда будут автоматически загружаться фотографии с веб-камеры:

$ google picasa create WebCamera

При первом обращении к сервису Picasa автоматически откроется страница в веб-браузере, в которой следует нажать кнопку «Разрешить», чтобы предоставить GoogleCL права на управление сервисом. После этого можно вернуться в терминал и нажать Enter.

Теперь нам нужно научиться делать сам снимок. Для этого можно использовать mplayer. Сначала запускаем в тестовом режиме:

$ mplayer tv://

Если получили на экран картинку с другого подключенного видеоустройства (TV-тюнер, например) или с другой камеры, перебираем все устройства в поисках нужного, меняя video0 на video1, video2 и так далее:

$ mplayer tv:// -tv device=/dev/video0

Если картинка перевернута, применяем фильтр:

$ mplayer tv:// -vf flip

Пробуем сделать снимок:

$ mplayer tv:// -frames 3 -vo jpeg

Получаем три снимка: 00000001.jpg, 00000002.jpg и 00000003.jpg. Это три последовательных кадра. Такое количество нужно потому, что многие дешевые камеры просто не успевают инициализироваться и вместо нормального изображения поначалу выдают кашу (у меня первый кадр — зеленый экран, второй — съехавшая картинка, третий — нормальный снимок). Теперь все, что нужно, — это написать скрипт, который будет делать снимок и загружать его в Picasa. У меня получилось вот что:

$ vi ~/bin/webcamera-picasa.sh #!/bin/sh mplayer tv:// -frames 3 -vf flip -vo jpeg DATE=`date +%F-%H-%M` mv 00000003.jpg ${DATE}.jpg google picasa post WebCamera ${DATE.jpg} --title ${DATE} rm -f 0000*.jpg ${DATE}.jpg

Это все, теперь на скрипт можно поставить бит исполнения и использовать его для каких угодно целей. Например, добавить в cron задание, которое будет запускать его каждый час или каждый день. Все снимки будут иметь имя в виде времени съемки, и ты в любой момент сможешь посмотреть их в Google+, где бы ты ни находился. Таким же образом, кстати, можно организовать загрузку фотографий в Dropbox, просто заменив предпоследнюю строку на «mv ${DATE}.jpg ~/Dropbox/».

Автозагрузка видео в YouTube

Таким же образом можно организовать автоматическую съемку и загрузку видео в YouTube. Для этого сначала разрешим GoogleCL работать с сервисом:

$ google youtube list

Как в случае с Picasa, вводим адрес своей электронной почты и нажимаем «Разрешить» в открывшемся окне. Далее можно попробовать загрузить тестовое видео для проверки работоспособности:

$ google youtube post video.avi --access=private --category Education
Загружаем видео в YouTube
Загружаем видео в YouTube

Видео будет загружено в раздел Education (YouTube требует указания имени раздела) и сделано приватным, так что никто, кроме тебя, его не увидит. В случае успешной загрузки ты получишь ссылку на видео. Если все ОK, можно приступать к реализации скрипта. Выглядеть он будет так:

$ vi ~/bin/webcamera-youtube.sh #!/bin/sh TIME='1:00' DATE=`date +%F-%H-%M` mencoder tv:// -fps 15 -vf flip -ovc lavc -lavcopts vcodec=mpeg4 -nosound -endpos $TIME -o ${DATE}.mpg google youtube post ${DATE}.mpg --access=private --category Education rm -f ${DATE}.mpg

Для съемки здесь использован mencoder с преобразованием в формат MPEG4. Длительность съемки указана в переменной TIME и по умолчанию составляет одну минуту. Сразу после окончания съемки видео будет загружено в YouTube показанным выше способом. Как и в случае с Picasa, вместо публикации в YouTube видео можно просто скопировать в Dropbox: «cp ${DATE}.mpg ~/Dropbox».

Автоматически загруженное видео в YouTube
Автоматически загруженное видео в YouTube

Такой скрипт можно использовать разными способами, включая запуск съемки по запросу через SSH или какой-нибудь Google Talk, либо добавить в задание cron и регулярно получать сводки с места событий в свой аккаунт в YouTube.

Аудит системных событий в Linux

Грамотная после-установочная настройка Linux-дистрибутива – лишь первый шаг на пути к безопасности и стабильности. Чтобы операционная система и дальше продолжала отвечать этим требованиям, придется приучить себя к постоянному слежению за ее состоянием. Этого можно достичь с помощью мониторинга и анализа лог-файлов, однако получение полного контроля над системой возможно только с помощью аудита системных событий.

Перед тем как перейти к основной части статьи, постараемся разобраться с тем, что же все-таки представляет собой системный аудит (или аудит системных событий). По самой своей сути это не что иное, как постоянное и подробное протоколирование любых событий, происходящих в операционной системе. Аудиту могут быть подвержены такие события, как чтение/запись файлов, выполнение входа в ОС, запуск и остановка приложений, инициация сетевого соединения и многое, многое другое. Linux, как и любая другая современная серверная ОС, включает в себя все необходимые инструменты для проведения аудита системы, однако разобраться в них с наскоку не так-то просто.

Система аудита ядра 2.6

Начиная с версии 2.6, ядро Linux включает в себя подсистему, специально разработанную для проведения аудита. Она позволяет вести слежение за такими системными событиями, как:

  • Запуск и завершение работы системы (перезагрузка, остановка);
  • Чтение/запись или изменение прав доступа к файлам;
  • Инициация сетевого соединения или изменение сетевых настроек;
  • Изменение информации о пользователе или группе;
  • Изменение даты и времени;
  • Запуск и остановка приложений;
  • Выполнение системных вызовов.

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

Установка

Демон auditd доступен в любом современном Linux-дистрибутиве и может быть установлен с помощью стандартного менеджера пакетов. Например, чтобы установить auditd в Debian/Ubuntu, достаточно выполнить следующую команду:

$ sudo apt-get install auditd

Кроме самого демона, вместе с пакетом будут установлены три подсобные утилиты, используемые для управления системой аудита и поиска записей в журнальных файлах:

  • auditctl – утилита, управляющая поведением системы аудита. Позволяет узнать текущее состояние системы, добавить или удалить правила;
  • autrace – аудит событий, порождаемых указанным процессом (аналог strace);
  • ausearch – команда, позволяющая производить поиск событий в журнальных файлах;
  • aureport – утилита, генерирующая суммарные отчеты о работе системы аудита;

По умолчанию система аудита находится в спящем состоянии и не реагирует ни на какие события (ты можешь убедиться в этом, выполнив команду «sudo auditctl -l»). Чтобы заставить систему сообщать нам подробности каких-либо событий, необходимо добавить правила. Но чтобы понять, как их составлять, придется разобраться с тем, как работает подсистема аудита ядра Linux.

Аудит системных событий

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

Именно это делает подсистема аудита. Она устанавливает триггеры до и после всех функций, ответственных за обработку системных вызовов, и ждет. Когда происходит системный вызов, триггер срабатывает, подсистема аудита получает всю информацию о вызове и его контексте, передает ее демону auditd и отдает дальнейшее управление функции, обрабатывающей системный вызов. После ее завершения срабатывает «выходной» триггер, и вся информация о системном вызове вновь поступает к подсистеме аудита и демону auditd.

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

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

Правила аудита

Для создания, удаления и модификации правил аудита предназначена утилита auditctl. Есть три основных опции, которые принимает эта команда:

  • -a – добавить правило в список;
  • -d – удалить правило из списка;
  • -D – удалить все правила;
  • -l – вывести список заданных правил.

Если ты сейчас выполнишь команду «auditctl -l» от имени администратора, то, скорее всего, увидишь «No rules», а это значит, что ни одного правила аудита еще не существует. Для добавления правил используется следующая форма записи команды auditctl:

# auditctl -a список,действие -S имя_системного_вызова -F фильтры

Здесь список – это список событий, в который следует добавить правило. Всего существует пять списков:

  • task – события, связанные с созданием процессов;
  • entry – события, происходящие при входе в системный вызов;
  • exit – события, происходящие во время выхода из системного вызова;
  • user – события, использующие параметры пользовательского пространства, такие как uid, pid и gid;
  • exclude – используется для исключения событий.

Не беспокойся, если смысл списков кажется тебе непонятным. По сути, это всего лишь фильтры, которые позволяют сделать правила более точными. На деле из них используются только entry и exit, которые позволяют зарегистрировать либо сам факт обращения к системному вызову, либо его успешную отработку.

Второй параметр опции – ‘-a’ – это действие, которое должно произойти в ответ на возникшее событие. Их всего два: never и always. В первом случае события не записываются в журнал событий, во втором – записываются.

Далее указывается опция ‘-S’, которая задает имя системного вызова, при обращении к которому должен срабатывать триггер (например, open, close, exit, и т.д.). Вместо имени может быть использовано числовое значение.

Необязательная опция ‘-F’ используется для указания дополнительных параметров фильтрации события. Например, если мы хотим вести журнал событий, связанных с использованием системного вызова open(), но при этом желаем регистрировать только обращения к файлам каталога /etc, то должны использовать следующее правило:

# auditctl -a exit,always -S open -F path=/etc/

Чтобы еще более сузить круг поисков, сделаем так, чтобы регистрировались только те события, при которых файл открывается только на запись и изменение атрибутов:

# auditctl -a exit,always -S open -F path=/etc/ -F perm=aw

Здесь ‘a’ – изменение атрибута (то есть attribute change), а ‘w’ – запись (то есть write). Также можно использовать ‘r’ – чтение (read) и ‘x’ – исполнение (execute). Другие полезные фильтры включают в себя: pid – события, порождаемые указанным процессом, apid – события, порождаемые указанным пользователем, success – проверка на то, был ли системный вызов успешным, a1, a2, a3, a4 – первые четыре аргумента системного вызова. Фильтр key используется для указания так называемого ключа поиска, который может быть использован для поиска всех событий, связанных с этим ключом. Количество возможных фильтров достаточно велико, их полный список можно найти в man-странице auditctl.

Вообще, для слежения за файлами в auditctl предусмотрен специальный синтаксис, при котором опцию ‘-S’ можно опустить. Например, описанное выше правило может быть задано следующим образом (здесь опция ‘-p’ – это эквивалент фильтра perm):

# auditctl -a exit,always -F dir=/etc/ -F perm=wa

Или используя более короткую форму (здесь оцпия ‘-p’ – это эквивалент фильтра perm, а ‘-k’ – фильтра key):

# auditctl -w /etc/ -p wa -k access_etc

Таким же образом может быть установлена «слежка» за любым индивидуальным файлом:

# auditctl -w /etc/passwd -p wa

Конфигурационные файлы

Правила не обязательно задавать, используя командную строку. Во время старта демон auditd читает два файла: /etc/audit/auditd.conf и /etc/audit/audit.rules (в некоторых дистрибутивах они могут находиться прямо в /etc). Первый описывает конфигурацию демона и содержит такие опции, как имя журнала, его формат, частота обновления и другие параметры. Нет смысла их изменять, разработчики дистрибутива уже позаботились о грамотной настройке.

Второй файл содержит правила аудита в формате auditctl, поэтому все, что нужно сделать, чтобы получить правило, пригодное для записи в этот файл – просто опустить имя команды. Например:

-w /etc/passwd -p wa

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

# Удаляем все правила из всех списков
-D

# Указываем количество буферов, хранящих сообщения аудита
-b 8192

# Что делать в чрезвычайной ситуации (например, если все буферы будут заполнены)

0 – ничего не делать

1 – поместить сообщение в dmesg

2 – отправить ядро в панику (kernel panic)

-f 1

Далее можно разместить свои правила.

Примеры правил

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

# vi /etc/audit/audit.rules

# Наблюдение за конфигурационными файлами
-w /etc/audit/auditd.conf -p wa
-w /etc/audit/audit.rules -p wa
-w /etc/libaudit.conf -p wa
-w /etc/default/auditd -p wa

# Наблюдение за журнальными файлами
-w /var/log/audit/
-w /var/log/audit/audit.log

Далее установим наблюдение за наиболее важными системными конфигурационными файлами. Изменение хотя бы одного из них может привести к открытию дыры в безопасности системы, чего допустить нельзя. Обрати внимание, что некоторые файлы актуальны только для дистрибутивов Debian/Ubuntu!

# vi /etc/audit/audit.rules

# Настройки и задания at
-w /var/spool/at
-w /etc/at.allow
-w /etc/at.deny

# Задания cron
-w /etc/cron.allow -p wa
-w /etc/cron.deny -p wa
-w /etc/cron.d/ -p wa
-w /etc/cron.daily/ -p wa
-w /etc/cron.hourly/ -p wa
-w /etc/cron.monthly/ -p wa
-w /etc/cron.weekly/ -p wa
-w /etc/crontab -p wa
-w /var/spool/cron/root

# Файлы паролей и групп
-w /etc/group -p wa
-w /etc/passwd -p wa
-w /etc/shadow

# Конфигурационные и журнальные файлы входа в систему
-w /etc/login.defs -p wa
-w /etc/securetty
-w /var/log/faillog
-w /var/log/lastlog

# Список и имена хостов
-w /etc/hosts -p wa

# Стартовые скрипты демонов
-w /etc/init.d/
-w /etc/init.d/auditd -p wa

# Пути поиска библиотек
-w /etc/ld.so.conf.d
-w /etc/ld.so.conf -p wa

# Настройки времени
-w /etc/localtime -p wa

# Системные переменные
-w /etc/sysctl.conf -p wa

# Правила загрузки модулей
-w /etc/modprobe.d/

# Модули системы PAM
-w /etc/pam.d/

# Настройки сервера SSH
-w /etc/ssh/sshd_config

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

# vi /etc/audit/audit.rules

# Изменение прав доступа к файлам
-a entry,always -S chmod -S fchmod -S chown -S chown32 -S fchown -S fchown32 -S lchown -S lchown32

# Создание, открытие или изменение размеров файлов
-a entry,always -S creat -S open -S truncate -S truncate64 -S ftruncate -S ftruncate64

# Создание и удаление каталогов
-a entry,always -S mkdir -S rmdir

# Удаление или создание ссылок
-a entry,always -S unlink -S rename -S link -S symlink

# Изменение расширенных атрибутов файлов
-a entry,always -S setxattr
-a entry,always -S lsetxattr
-a entry,always -S fsetxattr
-a entry,always -S removexattr
-a entry,always -S lremovexattr
-a entry,always -S fremovexattr

# Создание файлов устройств
-a entry,always -S mknod

# Монтирование файловых систем
-a entry,always -S mount -S umount -S umount2

# Использование системного вызова ptrace для отладки процессов
-a entry,always -S ptrace

Анализ журнальных файлов

Журнальные файлы, создаваемые демоном auditd в каталоге /var/log/audit, не предназначены для чтения человеком, но хорошо подходят для анализа с помощью специальных утилит, устанавливаемых вместе с самим демоном. Самая важная из них – утилита aureport, генерирующая отчеты из лог-файлов. Вызвав ее без аргументов, мы узнаем общую статистику использования системы, включая такие параметры, как количество входов и выходов из системы, открытых терминалов, системных вызовов и т.д. Эта информация малоинтересна, поэтому лучше запросить более детальный отчет. Например, запустив команду с флагом ‘-f’, мы получим список файлов, к которым происходил доступ:

$ sudo aureport -f

Скорее всего вывод будет слишком длинным, но его можно сократить с помощью запроса информации только за определенный период времени (аргумент ‘–end’ не обязателен):

$ sudo aureport -f --start 08/20/10 12:00 --end 08/20/10 13:00

Кроме числового значения времени можно использовать следующие специальные сокращения: now (сейчас), recent (десять минут назад), today (начиная с полуночи), yesterday (вчерашние сутки), this-week (неделя), this-month (месяц) или this-year (год). Вывод команды разбит на несколько столбцов, которые имеют следующие значения (слева направо):

  1. Просто числовой индекс;
  2. Дата возникновения события;
  3. Время возникновения события;
  4. Имя файла;
  5. Номер системного вызова (чтобы увидеть его имя, используй флаг ‘-i’);
  6. Успешность системного вызова (yes или no);
  7. Имя процесса, вызвавшего событие;
  8. Audit UID (AUID). О нем читай ниже;
  9. Номер события.

Вывод этой команды также можно существенно сократить, если указать флаг ‘–summary’, который заставляет aureport выводить не все случаи доступа к файлом, а только их общее количество по отношению к каждому из файлов:

$ sudo aureport -f -i --start recent --summary

Вывод команды будет разбит на две колонки, первая из которых отражает количество попыток доступа к файлу (успешных или нет), а вторая – его имя. Просматривая суммарный отчет использования файлов и заметив подозрительную попытку доступа к одному из системных/скрытых/личных файлов, можно вновь вызвать aureport, чтобы найти процесс, который произвел эту попытку:

$ sudo aureport -f -i --start today | grep /etc/passwd

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

$ sudo auserch -a номер_события

Также ausearch можно использовать для поиска событий по именам системных вызовов:

$ sudo ausearch -sc ptrace -i

Идентификаторам пользователей:

$ sudo ausearch -ui 2010

Именам исполняемых файлов:

$ sudo ausearch -x /usr/bin/nmap

Имени терминала:

$ sudo ausearch -tm pts/0

Именам демонов:

$ sudo ausearch -tm cron

Или ключам поиска:

$ sudo auserch -k etc_access

Вывод ausearch также может быть сокращен с помощью использования временных промежутков, наподобие тех, что мы использовали при вызове aureport. Сам aureport позволяет генерировать отчеты не только по использованию файлов, но и многих других типов событий, как, например, системные вызовы (флаг ‘-s’), попытки аутентификации (флаг ‘-au’) , успешные логины (флаг ‘-l’), модификации аккаунта (флаг ‘-m’) и многих других (полный список смотри в man-странице). Отчеты можно получать только для событий, завершившихся неудачно (флаг ‘–failed’).

AUID и PAM

Во время своей работы в системе пользователь может использовать команды su или sudo для изменения своего системного идентификатора (UID), из-за чего процесс отслеживания его деятельности существенно усложняется. Чтобы обойти эту проблему система аудита использует так называемые Audit UID (AUID), которые закрепляются за каждым пользователем во время его входа в систему и остаются неизменными даже несмотря на смену пользователем своего UID с помощью su или sudo. Однако, по умолчанию функция присваивания AUID отключена (именно поэтому восьмой столбец вывода aureport всегда содержит значение -1), и, чтобы ее активировать, необходимо отредактировать некоторые конфигурационные файлы PAM. Для этого открой файл /etc/pam.d/login и добавь строку «session required pam_loginuid.so» перед строкой «session include common-session». Таким же образом измени конфигурационные файлы /etc/pam.d/sshd, /etc/pam.d/gdm (kdm, если ты используешь среду KDE), /etc/pam.d/crond и /etc/pam.d/atd.

Выводы

Система аудита – достаточно низкоуровневый компонент Linux, который требует глубоких знаний ОС для своей настройки и анализа журнальных файлов. Однако, разобравшись в нем, ты получишь мощнейший инструмент слежения за системой, который поможет обнаружить аномалии в поведении системы и найти их виновника.

WARNING

Чтобы изменения, внесенные тобой в конфигурационные файлы демона auditd, вступили в силу, необходимо перезагрузить демон с помощью команды «/etc/init.d/auditd restart».

Использование Zabbix для мониторинга критических систем

Введение

Начнем с архитектуры. Система мониторинга Zabbix состоит из нескольких подсистем, причем все они могут размещаться на разных машинах:

  • сервер мониторинга, который периодически получает и обрабатывает данные, анализирует их и производит в зависимости от ситуации определенные действия, в основном оповещение администратора;
  • база данных — в качестве таковой могут использоваться SQLite, MySQL, PostgreSQL и Oracle;
  • веб-интерфейс на PHP, который отвечает за управление мониторингом и действиями, а также за визуализацию;
  • агент Zabbix, запускается на той машине/устройстве, с которой необходимо снимать данные. Его наличие хоть и желательно, но, если установить его на устройство невозможно, можно обойтись SNMP;
  • Zabbix proxy — используется в основном в тех случаях, когда необходимо мониторить сотни и тысячи устройств для снижения нагрузки на собственно сервер мониторинга.

Логическая единица мониторинга — узел. Каждому узлу присваивается описание и адрес — в качестве адреса можно использовать как доменное имя, так и IP. Узлы могут объединяться в группы, к примеру группа роутеров, для удобства наблюдения. Каждому серверу соответствует несколько элементов данных, то есть отслеживаемых параметров. Поскольку для каждого сервера настраивать параметры, за которыми нужно следить, неудобно (особенно это верно для больших сетей), можно создавать узлы-шаблоны и каждому серверу или группе серверов будет соответствовать несколько шаблонов.

В статье будут рассмотрены интересные сценарии использования Zabbix, но сначала опишем установку этого решения на RHEL-подобные системы с MySQL в качестве БД.

Установка и первичная настройка

Перво-наперво надо подключить репозиторий EPEL:

# yum install http://ftp.yandex.ru/epel/6/i386/epel-release-6-8.noarch.rpm

Затем поставить нужные пакеты:

# yum install zabbix20-server zabbix20-agent zabbix20-web-mysql nmap httpd policycoreutils-python net-snmp net-snmp-utils
# yum groupinstall "MySQL Database Client" "MySQL Database Server"

Для чего нужен httpd и утилиты SNMP, полагаю, понятно. А вот Nmap нужен для некоторых проверок, чтобы заполнить элементы данных. Теперь необходимо настроить автозапуск служб и их запустить.

# chkconfig httpd on
# chkconfig mysqld on
# chkconfig zabbix-server on
# chkconfig zabbix-agent on
# service mysqld start

И конечно же, надо произвести начальную настройку MySQL.

# mysql_secure_installation

Затем заходим в консоль MySQL и создаем БД и пользователя:

mysql> CREATE DATABASE zabbix CHARACTER SET utf8;
mysql> GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'localhost' IDENTIFIED BY 'zabbixpassword';

Теперь импортируем базы данных:

# mysql -u zabbix -p zabbix < /usr/share/zabbix-mysql/schema.sql
# mysql -u zabbix -p zabbix < /usr/share/zabbix-mysql/images.sql
# mysql -u zabbix -p zabbix < /usr/share/zabbix-mysql/data.sql

Редактируем файл конфигурации сервера Zabbix (/etc/zabbix_server.conf):

# <...>
DBHost=localhost
DBName=zabbix
DBUser=zabbix
DBPassword=zabbix

Слегка подкрутим конфигурацию PHP (/etc/php.ini):

# <...>
max_execution_time = 300
max_input_time = 300
post_max_size = 16M
date.timezone = Asia/Omsk

Настраиваем SELinux:

# semanage port -a -t http_port_t -p tcp 10051
# setsebool -P httpd_can_network_connect on

Наконец, запускаем оставшиеся службы:

# service httpd start
# service zabbix-server start
# service zabbix-agent start

В браузере подключаемся к http://server_name/zabbix и производим начальную конфигурацию фронтенда Zabbix (то есть имя БД, имя пользователя и пароль). После этого начальную настройку можно считать завершенной.

Конфигурационный файл Zabbix-сервера

Начальная страница настройки веб-интерфейса Zabbix

Примерно так выглядит начальная страница в первый раз после захода на нее

Мониторинг nginx и memcache

Для мониторинга nginx можно, разумеется, использовать самописные скрипты. Но в некоторых случаях, когда времени катастрофически не хватает, хочется найти что-нибудь готовое. В случае с nginx таким готовым решением будет набор питоновских скриптов ZTC. Для их установки сперва нужно установить некоторые пакеты:

# yum install lm_sensors smartmontools

Затем используй следующие команды:

# wget https://bitbucket.org/rvs/ztc/downloads/ztc-12.02.1-1.el6.noarch.rpm
# rpm -ivh --nodeps ztc-12.02.1-1.el6.noarch.rpm

Опция –nodeps нужна по причине того, что пакет требует версию Zabbix 1.8, но ничто не мешает попробовать ZTC и на последних его версиях.

Теперь добавим еще один конфиг nginx (/etc/nginx/conf.d/nginx_status.conf):

server {
    listen localhost;
     server_name nginx_status.localhost;
     location /server-status {
        stub_status on;
        access_log off;
        allow 127.0.0.1;
        deny all;
    }
}

И поправим конфиг nginx в ZTC (/etc/ztc/nginx.conf):

# <...>
proto=http
host=localhost
port=80
resource=/server-status

Проверим работу скрипта ZTC:

# /opt/ztc/bin/nginx.py ping
# /opt/ztc/bin/nginx.py ping

Если все нормально, настраиваем Zabbix-agent на нужной машине (/etc/zabbix-agentd.conf):

# <...>
UserParameter=nginx[*],/opt/ztc/bin/nginx.py $1

Теперь нужно настроить веб-интерфейс. Для этого необходимо импортировать шаблонTemplate_app_nginx.xml, что лежит в /opt/ztc/templates/. Замечу, что лежит он именно на том компьютере, где установлен ZTC, так что если у тебя на сервере нет GUI, то файл придется копировать на машину, на которой установлен браузер и с которой собственно и ведется мониторинг.

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

А вот для memcache среди этих скриптов нет ничего, так что придется нам его написать самим. Проверим его работо- и дееспособность:

# echo -e "stats\nquit" | nc -q2 127.0.0.1 11211

В ответ должны посыпаться статистические данные. Теперь пишем скрипт-однострочник/etc/zabbix/scripts/memcache.sh (при этом не забываем сделать его исполняемым):

#!/bin/bash
echo -e "stats\nquit" | nc 127.0.0.1 11211 | grep "STAT $1 " | awk '{print $3}'

Как и в случае с nginx, правим конфиг Zabbix-agent (/etc/zabbix-agentd.conf) и не забываем его рестартовать:

# <...>
UserParameter=memcache[*],/etc/zabbix/scripts/memcache.sh $1

Берем шаблон отсюда и импортируем его в веб-интерфейс.

Проверка работоспособности скриптов ZTC

Страница импорта шаблона

Для сети средних размеров (когда нужно мониторить около десятка устройств) достаточно разместить сервер мониторинга, веб-интерфейс и БД на одной системе, а Zabbix-агенты — на узлах, требующих присмотра.

Мониторинг различных устройств с помощью Zabbix

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

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

  • включить поддержку SNMP на устройствах. Не забывай о безопасности — по возможности используй третью версию протокола, устанавливай авторизацию и изменяй имена community;
  • добавить нужные элементы в Zabbix. Одному параметру SNMP соответствует один элемент; также нужно указать OID (идентификатор параметра) версию SNMP и, в зависимости от нее, параметры авторизации;
  • добавить триггеры на нежелательное изменение параметров.

У каждой железки могут быть десятки отслеживаемых параметров, и вручную их добавлять замучаешься. Но в Сети можно найти множество шаблонов, которые уже содержат в себе все необходимые элементы, триггеры и графики, — остается только их импортировать и подключить нужные хосты. Также существуют стандартные OID, которые описаны в RFC. К таковым относится, например, uptime с OID .1.3.6.1.2.1.1.3.0 или — для коммутаторов — статус порта с OID .1.3.6.1.2.1.2.2.1.8.X, где X — номер порта.

Существует онлайн-генератор шаблонов, который генерирует их на основе стандартных OID. В основном он предназначен для железа от Cisco, но ничто не мешает его использовать для другого оборудования.

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

Тот же человек, что написал упомянутый генератор шаблонов, написал также и дополнение к фронтенду, которое отображает в удобном виде статус порта (скрипт для второго Zabbix лежит здесь). Установка его, как его автор сам и признает, достаточно заморочена — скрипт писался в первую очередь для внутреннего применения.

SNMP Traps в Zabbix

Протокол SNMP, помимо пассивного получения данных устройства, поддерживает также и активную их рассылку со стороны устройства. В англоязычной документации это именуется SNMP Trap, в русскоязычной же используется термин SNMP-трап. Трапы удобны, когда нужно срочно уведомить систему мониторинга об изменении какого-либо параметра. Для отлова трапов в Zabbix имеется три способа (во всех трех случаях нужен еще и демон snmptrapd):

  • с помощью SNMPTT (SNMP Trap Translator);
  • используя скрипт на Perl;
  • используя скрипт на bash.

Далее описан первый вариант. Прежде всего, не забываем разрешить 161-й порт UDP и по необходимости временно отключить SELinux. Затем ставим нужные пакеты (предполагается, что репозиторий EPEL у тебя подключен):

# yum install net-snmp net-snmp-utils net-snmp-perl snmptt

Настраиваем snmptrapd (/etc/snmp/snmptrapd.conf):

disableAuthorization yes
traphandle default snmptthandler

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

Затем настраиваем snmptt (/etc/snmp/snmptt.ini):

# <...>
net_snmp_perl_enable = 1
mibs_environment = ALL
date_time_format = %H:%M:%S %Y/%m/%d

Теперь нужно настроить шаблоны для маппинга трапов на Zabbix SNMP. Ниже будет приведен пример такого шаблона для двух видов трапов — coldStart и всех остальных (/etc/snmp/snmptt.conf).

# <...>
EVENT general .* "General event" Normal
FORMAT ZBXTRAP $aA $1
EVENT coldStart .1.3.6.1.6.3.1.1.5.1.0.33 "Status Events" Normal
FORMAT ZBXTRAP $aA Device reinitialized (coldStart)

Первые две строчки описывают любые трапы, а вторая пара — конкретный трап с OID. Замечу, что для того, чтобы Zabbix ловил эти трапы, они должны быть именно в формате «ZBXTRAP адрес».

Включаем нужные службы:

# chkconfig snmptt on
# chkconfig snmptrapd on
# service snmptt start
# service snmptrapd start

Посылаем тестовые трапы и смотрим логи:

# snmptrap -v 1 -c public 127.0.0.1 '.1.3.6.1.6.3.1.1.5.1' '0.0.0.0' 6 1 '55' .1.3.6.1.6.3.1.1.5.1 s "teststring000"
# snmptrap -v 1 -c public 127.0.0.1 '.1.3.6.1.6.3.1.1.5.1' '0.0.0.0' 6 33 '55' .1.3.6.1.6.3.1.1.5.1 s "teststring000"
# tail /var/log/snmptt/snmptt.log

Если все нормально, переходим к конфигурированию Zabbix. В файле/etc/zabbix_server.conf укажем местонахождение лога и включим встроенный SNMPTrapper:

# <...>
SNMPTrapperFile=/var/log/snmptt/snmptt.log
StartSNMPTrapper=1

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

Шаблоны для маппинга SNMP-трапов

Настройка трапов в веб-интерфейсе

Масштабирование в Zabbix работает достаточно хорошо — при должной настройке он выдерживает 6000 узлов.

Мониторинг VPN-туннелей на оборудовании Cisco

Возникла необходимость мониторинга загрузки кучи туннелей VPN на цисках. Все хорошо, SNMP как на циске, так и на Zabbix настроен, но есть одна загвоздка — OID для каждого соединения формируются динамически, как и их списки. Это связано с особенностями протокола IPsec, в которые я вдаваться не буду — скажу лишь, что это связано с процедурой установления соединения. Алгоритм извлечения нужных счетчиков, таким образом, настолько замудрен, что реализовать его встроенными средствами Zabbix не представляется возможным.

По счастью, имеется скрипт, который это делает сам. Его нужно скачать и закинуть в каталог ExternalScripts (в моем случае это был /var/lib/zabbixsrv/externalscripts). Проверим его работоспособность:

# /var/lib/zabbixsrv/externalscripts/query_asa_lan2lan.pl ciscocom 192.168.10.1 ASA get RX 94.251.99.1

Если проверка прошла успешно, применим комбинацию LLD с этим скриптом. Создаем шаблон с правилом обнаружения (OID 1.3.6.1.4.1.9.9.171.1.2.3.1.7) и двумя элементами данных с внешней проверкой и ключами ‘queryasalan2lan.pl[“{$SNMPCOMMUNITY}”, “{HOST.IP}”, “ASA”, “get, “RX”, “{#SNMPVALUE}”]’ и ‘queryasalan2lan.pl[“{$SNMPCOMMUNITY}”, “{HOST.IP}”, “ASA”, “get”, “TX”, “{#SNMPVALUE}”]’, назвав их соответственно “Incoming traffic in tunnel to {#SNMPVALUE}” и “Outgoing traffic in tunnel to {#SNMPVALUE}”. После этого применяем шаблон к нужным узлам и ждем автообнаружения.

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

Сайт, где можно найти всяческие MIB-файлы: www.oidview.com

Прикручиваем MIB к Zabbix

Сам по себе Zabbix не поддерживает MIB (Management Information Base), а готовые шаблоны есть отнюдь не для всех устройств. Конечно, все OID можно добавить и вручную (с помощью snmpwalk), но это работает, только если их у тебя не очень много. Однако существует плагин для веб-интерфейса Zabbix под названием SNMP Builder, который позволяет конвертировать MIB-файлы в шаблоны и уже эти шаблоны допиливать под свои нужды. Берем его из Git-репозитория:

# git clone https://github.com/atimonin/snmpbuilder.git

Накладываем патч (в твоем случае, разумеется, имена каталогов могут быть другими, и подразумевается, что ты находишься в каталоге, где размещен фронтенд Zabbix — в случае с RHEL-based системами это /usr/share/zabbix):

# patch -p1 < /home/centos/snmpbuilder/snmpbuilder-2.0.5.patch

Копируем недостающие файлы и распаковываем картинки:

# tar xzvf /home/centos/snmpbuilder/snmpbuilder-2.0_imgs.tar.gz
# cp -r  /home/centos/snmpbuilder/zabbix/* .

По необходимости редактируем переменную MIBSALLPATH в файле snmp_builder.php. В отдельных случаях может также понадобиться слегка подправить его код, начиная со строки foreach(glob($path.”/*.mib”). Код в этом случае будет выглядеть примерно так:

# <...>
foreach(glob($path."/*.mib") as $filename){
    if (preg_match('/^'.preg_quote($path,'/').'\/(.+)\.mib$/',$filename,$matches)){
        $result=exec("cat ".$filename."| grep -i 'DEFINITIONS.*::=.*BEGIN'|awk '{print $1}'");
        $cmbMibs->addItem($result,$result);
    }
}

Теперь можно уже использовать.

Прежде всего нужно найти MIB-файлы для твоего железа. Некоторые производители их скрывают, некоторые — нет. После того как ты их нашел, эти файлы нужно поместить в папку, которую ты указал в вышеуказанной переменной. В отдельных случаях могут возникнуть зависимости — в подобной ситуации нужно найти соответствующий MIB-файл, чтобы их разрешить. Итак, выбери шаблон, MIB-файл и укажи адрес устройства. Если все нормально, ты увидишь список OID, которые нужно затем выбрать для добавления к шаблону. После выбора нужно нажать кнопку «Сохранить». Добавленные элементы появятся в указанном шаблоне.

В отдельных ситуациях нужно отредактировать новодобавленные элементы, поскольку по дефолту интервал обновления 60 секунд, что в случае, например, с именем хоста не имеет особого смысла — лучше в подобных ситуациях ставить его равным 86 400 секунд (24 часа). Для счетчиков же нужно изменить формат хранения на «Дельта в секунду». Кроме того, с некоторыми элементами нужно настроить еще и преобразование их значений в удобочитаемый вид. Для этого перейди в «Администрирование -> Общие» и в выпадающем меню выбери «Преобразование значений», а там уже добавляй его.

В общем-то, модуль мы настроили — все остальное ты уже настраивай самостоятельно.

Версии протокола SNMP

Существует несколько версий SNMP. Первая версия появилась в 1988 году и на данный момент, хоть и считается устаревшей, все еще очень популярна. Версия 2 (фактически сейчас под ней подразумевают версию 2c) появилась в апреле 1993 года. Она была несовместима с первой версией. Основные новшества второй версии протокола заключались в обмене информацией между управляющими компьютерами. Кроме того, появилась команда получения сразу нескольких переменных (GetBulk).

Во времена разработки первой версии мало кто заботился о безопасности, поэтому о какой-либо защите в SNMPv1 и говорить нечего. Аутентификации как таковой не было — не считать же за нее строку Community, передаваемую в открытом виде? Были, конечно, попытки реализовать безопасность SNMPv1, но успехом они не увенчались. Во второй версии кардинальных изменений тоже не появилось. А вот SNMPv3 уже начала поддерживать как безопасность сообщений (USM), так и контроль доступа (VACM). В USM поддерживаются MD5 и SHA-1 для обеспечения защиты от модификации данных и DES (сейчас уже AES) для шифрования. VACM же вводит как возможность авторизации, так и возможность указывать, какой управляющий компьютер какими атрибутами может манипулировать.

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

Централизованный сбор Windows Event Logs с помощью ELK (Elasticsearch — Logstash — Kibana)

Передо мной встала задача организовать сбор Windows Event Logs в некое единое хранилище с удобным поиском/фильтрацией/возможно даже визуализацией. После некоторого поиска в интернете я натолкнулся на чудесный стек технологий от Elasticsearch.org — связка ELK (ElasticsearchLogstashKibana). Все продукты являются freeware и распространяются как в виде архива с программой, так и в виде пакетов deb и rpm.

Что такое ELK?

Elasticsearch

Elasticsearch — это поисковый сервер и хранилище документов основанное на Lucene, использующее RESTful интерфейс и JSON-схему для документов.

Logstash

Logstash – это утилита для управления событиями и логами. Имеет богатый функционал для их получения, парсинга и перенаправления\хранения.

Kibana

Kibana – это веб-приложение для визуализации и поиска логов и прочих данных имеющих отметку времени.

Read More «Централизованный сбор Windows Event Logs с помощью ELK (Elasticsearch — Logstash — Kibana)»

Ещё один вариант скрипта RAID-мониторинга использующего MegaCli (LSI) на CentOS

Первое, скачиваем MegaCLI с LSI сайта -> MegaCLI 2.00.11 for Linux

Распаковываем и устанавливаем его используя RPM. Файлы будут помещены в /opt/MegaRAID/MegaCli.

1. Создаём файл и называем его «analysis.awk» в папке /opt/MegaRAID/MegaCli со следующим содержимым:

# Это небольшая AWK программа интерпритирующая MegaCLI вывод

/Device Id/ { counter += 1; device[counter] = $3 }

/Firmware state/ { state_drive[counter] = $3 }

/Inquiry/ { name_drive[counter] = $3 » « $4 » « $5 » « $6 }

END {

Read More «Ещё один вариант скрипта RAID-мониторинга использующего MegaCli (LSI) на CentOS»

Скрипт для мониторинга за аппаратными рейдом поверх MegaCli

#!/bin/bash
#
# Calomel.org 
#     https://calomel.org/megacli_lsi_commands.html
#     LSI MegaRaid CLI 
#     lsi.sh @ Version 0.05
#
# description: MegaCLI script to configure and monitor LSI raid cards.

# Full path to the MegaRaid CLI binary
MegaCli="/usr/local/sbin/MegaCli64"

# The identifying number of the enclosure. Default for our systems is "8". Use
# "MegaCli64 -PDlist -a0 | grep "Enclosure Device"" to see what your number
# is and set this variable.
ENCLOSURE="8"
 Read More "Скрипт для мониторинга за аппаратными рейдом поверх MegaCli"

УСТАНОВКА И НАСТРОЙКА NAGIOS И NRPE ИЗ ИСХОДНИКОВ

Версия для начинающих чайников-пингвинов. Более детальный мануал. Установка из исходников.

Ставим Nagios.
Nagios позволяет следить за серверами и сервисами, а также ведет небольшую статику по всему этому, и вы можете видеть как работает ваш сервер(а), а также получать уведомления на почту об ошибках или критических проблемах.

Создаем юзверя и даем ему пароль

/usr/sbin/useradd -m nagios
passwd nagios

Создаем группу nagcmd и даем права на исполнение команд через веб-интерфейс, добавляем пользователя nagios и apache в эту группу

/usr/sbin/groupadd nagcmd
/usr/sbin/usermod -a -G nagcmd nagios
/usr/sbin/usermod -a -G nagcmd apache

Read More «УСТАНОВКА И НАСТРОЙКА NAGIOS И NRPE ИЗ ИСХОДНИКОВ»

УСТАНОВКА ZABBIX

Zabbix – это открытое решение распределенного мониторинга, позволяющее отслеживать статусы разнообразных сервисов компьютерной сети, сетевого и серверного оборудования. На данный момент актуальной версией Zabbix является версия 2.4, увидевшая свет в сентябре нынешнего года. С полным списком изменений и улучшений можно ознакомиться тут.

В этой статье мы расскажем как установить Zabbix на CentOS.

1)Первым делом добавим репозиторий Zabbix. Найти актуальный можно тут. Мы будем устанавливать версию 2.4 на CentOS:

2)Обновляем систему

3)Установим пакеты Zabbix

Read More «УСТАНОВКА ZABBIX»

Install Monitorix

Installation on a RedHat/Fedora/CentOS Linux

Install first the required packages.

# yum install httpd rrdtool rrdtool-perl perl-libwww-perl perl-MailTools perl-MIME-Lite perl-CGI

If yum fails installing one or more of these packages, then you could try to get them manually from these two additional repositories:

Both repositories are considered by many in the community to be stable and safe.

Download and install the Monitorix package.

Read More «Install Monitorix»

МОНИТОРИНГ SOFTWARE RAID LINUX

Какие средства кто знает для мониторинга soft raid на linux ? Кроме /proc/mdstat ничего в голову не приходит.Вот ещё способ:

mdadm —detail /dev/md2
/dev/md2:
Version : 00.90.03
Creation Time : Tue Jun 16 18:41:35 2009
Raid Level : raid1
Array Size : 293684160 (280.08 GiB 300.73 GB)
Used Dev Size : 293684160 (280.08 GiB 300.73 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 2
Persistence : Superblock is persistent

Update Time : Fri Oct 23 18:39:55 2009
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

UUID : 5345cce2:1e5da02a:776c2c25:004bd7b2
Events : 0.8

Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 8 19 1 active sync /dev/sdb3

А вот так смотреть статус в виде, удобном для скриптов:

mdadm —detail /dev/md0 | grep ‘State :’ | awk ‘{print $3}’

Для массива в «нормальном состоянии» выдача скрипт будет «clean»

MPT-STATUS PACKAGES FOR RHEL / CENTOS 5 AND 6

демон для хардварного рейда, который проверяет состояние и отсывалет письмо в случае пброблемы с дисками (если успеет;))

 

Here is my source rpm and some binary packages of the mpt-status utility build on CentOS 6 with mock for CentOS / RHEL 5 and 6.

git repository
SHA1SUMs

mpt-status with mpt-statusd init script

Starting with version 1.2.0-3 my package contains a port of the mpt-statusd init script from the Debian package. This feature requires the daemonize package, which is currently available from the EPEL repository (thanks to Sven Lankes and Niels de Vos #746783).

RHEL / CentOS 6: i686 x86_64 SRPM

RHEL / CentOS 5: i386 x86_64 SRPM

daemonize EPEL 6: i686 x86_64 SRPM

daemonize EPEL 5: i386 x86_64 SRPM

mpt-status

Up to version 1.2.0-2 the package contained only the mpt-status binary, which omits the depedency on daemonize.

RHEL / CentOS 6: i686 x86_64 SRPM

RHEL / CentOS 5: i386 x86_64 SRPM