cd /usr/ports/databases/mysql51-server/
make install clean
mysql_install_db
chown –R mysql:mysql /var/db/mysql
echo mysql_enable=YES >> /etc/rc.conf
/usr/local/etc/rc.d/mysql-server start

Дальше запускаем консоль командой mysql

UPDATE mysql.user SET Password=PASSWORD('NEWROOTPASSWORD') WHERE User='root';
DELETE FROM mysql.user WHERE User='';
DELETE FROM mysql.user WHERE User='root' AND Host!='localhost';
DROP DATABASE test;
DELETE FROM mysql.db WHERE Db='test' OR Db='test\\_%';
FLUSH PRIVILEGES;
exit

Что мы сделали? В порядке выполнения команд получается так:

% uname -a
Linux servername.ru 2.6.18-164.15.1.el5.028stab068.9 #1 SMP Tue Mar 30 18:07:38 MSD 2010 x86_64 x86_64 x86_64 GNU/Linux
%

Т.е. конечно про ядро мне все тут рассказали, но вот какая версия CentOS? Загадка…
Попробовал иначе:

% cat /proc/version
Linux version 2.6.18-164.15.1.el5.028stab068.9 (root@rhel5-build-x64) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Tue Mar 30 18:07:38 MSD 2010
%

Уже лучше, теперь я знаю, что уши CentOS торчат из указанной версии RedHat… Хм, все равно не то!
Вот он, правильный вариант!

% cat /etc/redhat-release
CentOS release 5.4 (Final)
%

#/bin/sh

DEBUG=0

print_debug()
{
  if [ "x$DEBUG" != "x0" ]; then
    echo $* >&2
  fi
}

print_debug hello world

Переменная DEBUG, если не равно 0, указывает, что нужно выводить сообщения в функции print_debug. Обычное echo выводи строку со всеми аргументами функции (переменная $*) в stdout, которые перенаправляется в stderr ( >&2 ).

Цитирую opennet:
“Во FreeBSD обнаружены три опасные уязвимости:

• В коде NFS-клиента обнаружена уязвимость, позволяющая локальному злоумышленнику организовать выполнение кода в контексте ядра и получить привилегии суперпользователя. Для успешной эксплуатации уязвимости в системе должен быть активирован отключенный по умолчанию режим vfs.usermount, позволяющий обычным пользователям выполнять операции по монтированию разделов. Уязвимость вызвана ошибкой в коде проверки длины передаваемых при монтировании параметров. Проблеме подвержены все выпуски FreeBSD начиная с версии 7.2, в качестве временной меры достаточно запретить возможность монтирования непривилегированными пользователями (sysctl vfs.usermount=0). Разработчики отмечают, что даже после применения устраняющего уязвимость патча функции монтирования непривилегированными пользователями не могут быть отнесены к категории безопасных. Большинство реализаций файловых систем FreeBSD реализованы без оглядки на возможность злонамеренных действий (например, монтирование определенным образом поврежденной ФС). Несмотря на то, что подобные ошибки исправляются при обнаружении, полный аудит безопасности кода файловых систем не проводился.

• В реализации библиотеки для работы с одноразовыми паролями OPIE обнаружена возможность переполнения буфера, приводящая к записи дополнительного нулевого байта за конец стека. Ошибка позволяет удаленному злоумышленнику инициировать крах серверного процесса сервиса OPIE при включении в системе режима защиты от переполнения стека. Примечательно, что уязвимости подвержены все поддерживающие OPIE-аутентификацию системные сервисы, даже при отключении поддержки OPIE в системе. Например, можно удаленно вызвать крах ftpd. Не исключена, хотя и отнесена к маловероятным, возможность эксплуатации данной проблемы для организации атакующим выполнения своего кода на сервере. Проблеме подвержены все поддерживаемые выпуски FreeBSD (6.x, 7.x, 8.x). В качестве временной меры достаточно недопустить выполнение связанных с libopie.so серверных приложений.

• В утилите jail, через которую осуществляется запуск процесса в изолированном окружении, не производится по умолчанию смена текущей рабочей директории, что позволяет атакующему получить доступ к файлам вне изолированного окружения, если до момента запуска jail одним из родительских процессов был открыт файловый десктиптор, связанный с данной рабочей директорией. По умолчанию скрипт для инициализации Jail-окружений /etc/rc.d/jail не подвержен данной уязвимости, так как для запуска jail в нем используются опции “-l -U root” подразумевающие выполнение вызова chdir. Но если администратор в ручную убрал данные флаги путем использования своего набора параметров jail_*flags в rc.conf, данный скрипт может быть использован для совершения атаки. Проблеме подвержены только выпуски FreeBSD 8.x. В качестве временной меры достаточно при вызове Jail указывать параметры “-l -U root”.

Ссылки на официальном сайте FreeBSD:
FreeBSD-SA-10:06.nfsclient
FreeBSD-SA-10:05.opie
FreeBSD-SA-10:04.jail

Теория работы плагинов nagios

Фактически плагин nagios – это обычная программа, которая взаимодействует с системой мониторинга через коды возврата и стандартного вывода. Коды возврата сообщают nagios о результате проверки, а из стандартного вывода формируется сообщение для web интерфейса. Со стандартным выводом все несколько сложнее, но сперва расскажу про коды возврата. Всего есть четыре кода возврата, которые может передать плагин в систему мониторинга:

0 – OK, т.е. проверка выполнена удачно и все работает как нужно.
1 – WARNING, проверка выполнена успешно, но проверяемая служба выдает показатели, превышающие порог нормальной работы.
2 – CRITICAL, проверка выполнена, но проверяемая служба не работает, или выдает значения, превышающие критический порог.
3 – UNKNOWN, такой код возврата говорит о невозможности плагином выполнить проверку. Причин для этого может быть несколько, например были введены неверные аргументы для плагина проверки или плагин не может создать какой-то дочерний процесс, открыть tcp сокет и т.п.

Один из этих кодов возврата плагин должен вернуть в любом случае. Кроме того плагин должен вывести что-то в стандартный вывод. Причем есть несколько вариантов. В самом простом варианте это должна быть просто одна строка, например:
DISK OK – free space: / 3326 MB (56%);
Этот вывод будет показан в web интерфейсе. Кроме описания произведенной проверки и ее показателей, можно выводить статистику. для разделения вывода в web интерфейс и статистики используется символ | . Формат статистики:
‘название’=значение[размерность];[warn];[crit];[min];[max]

название – текстовое обозначение выводимой величины, например /, или ‘Disk /’. Замечу, что кавычки в названии требуются, только при использовании в нем пробела, знака равно или кавычек.
значение – результат проверки.
размерность – размерность не указывается для значений, показывающих число процессов, пользователей и т.п. Если значение в процентах, то и размерность нужно указать, как %. Аналогично для времени (s), размеров данных (B, KB, MB, TB). Для постоянно увеличивающихся счетчиков используется размерность c.
warn – порог предупреждения
crit – порог критического состояния
min и max - допустимые минимальное и максимальное значения. Для размерности % указывать их не нужно понятно почему.

Можно выводить несколько параметров через пробел. Т.е. получается что-то такое:
DISKS OK – free space: / 3326 MB (56%); /home 184053 MB (27%) | /=2643MB;5948;5958;0;5968 /home=69357MB;253404;253409;0;253414
Кроме того есть третий вариант, который работает в nagios 3.x. Помимо сообщения и статистики можно выводить длинное описание, еще несколько строк, как показано вот в этом примере:
DISK OK – free space: / 3326 MB (56%); | /=2643MB;5948;5958;0;5968
/ 15272 MB (77%);
/boot 68 MB (69%);
/home 69357 MB (27%);
/var/log 819 MB (84%); | /boot=68MB;88;93;0;98
/home=69357MB;253404;253409;0;253414
/var/log=818MB;970;975;0;980
Красным выделено сообщение, оранжевым статистика и синем длинное описание. Помните, я говорил, что сообщение выводится в web интерфейс, а тогда где используется статистика и длинное описание? На самом деле все несколько сложнее. Для обработка каждого из типов вывода используется отдельный макрос:

Например статистику можно использовать для построения графиков через команду service_perfdata_command.
Теперь пожалуй с теории покончено, осталось только сказать, что в nagios есть механизм защиты от вывода слишком большого объема информации плагином, nagios прочитает только 4КБ данные, все остальное будет отброшено.

Несколько советов о практике написания плагинов

Чтобы запустить проверку, т.е. наш плагин, на удаленном сервере нужна некая служба, которая получает команды на запуск плагина от сервера nagios и отдает ему результат проверки. Различные варианты реализации такой службы я бы хотел вынести в отдельную статью, а сейчас давайте поговорим о другой проблеме.
Многие проверки, например проверка состояния raid массива, требует прав суперпользователя. Т.е. у нас есть внешняя служба на сервер, которой с одной стороны очень не хочется давать права суперпользователя, а с другой проверки, которым эти права суперпользователя нужны!
Есть два наиболее часто используемых варианта запуска на удаленном сервере плагина:
1) Плагин check_by_ssh умеет запускать на удаленном сервере заданную команду, т.е. на сервере nagios запускается плагин check_by_ssh, которому в качестве параметров передается имя проверяемого хоста и команду, которую нужно запустить.
2) Служба NRPE, на проверяемом сервере запускается служба NRPE, в ее настройках прописаны команды, которые может “попросить” выполнить сервера nagios. На стороне сервера проверка выполняется аналогично варианту с SSH, вызывается плагин check_by_nrpe с параметрами хоста и имени запускаемой команды.
Теперь вернемся к нашей проблеме, нам нужно запустить проверку с правами суперпользователя.
Вариант первый – путь камикадзе. Запускаем службу nrpe от имени root или разрешаем заход по ключу root с сервера nagios. Проблема решена, можно запускать любой плагин с правами суперпользователя. Теперь рассмотрим проблемы с безопасностью, который возникают при таком решении. Запуск любой внешней службы с правами суперпользователя всегда потенциально опасен, если в ней есть критическая уязвимость, то получить после удачного эксплойда права nobody и права root – это две большие разницы. В принципе при жесткой настройке правил фаервола для nrpe, такой вариант имеет права на жизнь, но с точки зрения системного подхода к обеспечению безопасности это явный fail. Для check_by_ssh вроде бы такой проблемы нет. Но подумайте вот о чем, если сервера nagios будет взломан, то с большой вероятностью злоумышленник получит доступ на все остальные ваши сервера!
Вариант второй – sudo. Данный вариант уже намного лучше. На проверяемом сервере создается пользователь nagios, под которым запускается nrpe или по ключу которого заходит по ssh сервер nagios. В sudo в настройках прописаны правила запуска плагинов проверки для пользователя nagios. Такой вариант намного лучше с точки зрения безопасности, но в данном варианте атака может быть направлена на запускаемый плагин. Атака маловероятная, но возможная. При грамотной настройке фаервола и прочих мерах безопасности данный вариант наиболее часто используется на практике.
Вариант третий – разделение логики проверки на собственно проверку и получение данных сервером nagios. Т.е. плагин, который мы пишем имеет два варианта запуска. В одном он выполняет проверку с правами root и сохраняет результат в какой-то файл. Права на файл выставляются так, чтобы пользователь, от имени которого запускаются проверки, мог прочитать этот файл. Эта проверка запускается через cron. Второй же вариант запуска нужен для чтения фала с результатами проверки. Из нюансов – нужно помнить, что плагин должен уметь проверять время создания файла, так чтобы не получилось, что проверка по какой-то причине давно не работает, а плагин раз за разом читает давно созданный файл и сообщает, что все ОК. Вариант с разделенной логикой наиболее безопасен, но распространен не очень сильно, так как под него придется переписывать все распространенные плагины.
Вот наверное и все, что нужно для начала написания своего плагина.

add_log_message ()
{
 local logger='/usr/bin/logger'
 local tag='My Script'
 local port=514
 local host=localhost
 local facility='user'
 local level='notice'
 local message=$1
  if [ -z $message ]; then
        return 1
  else
    $logger -t "$tag" -p ${facility}.${level} -P $port -h $host "$message"
    if [ "x$?" != "x0" ]; then
        return 2
    fi
  fi
}

add_log_message 'Hello world'

Опция -t задает TAG, фактически TAG можно использовать для идентификации источника сообщения. Так же logger умеет отправлять сообщения syslog-у на другом сервер, т.е. легко можно организовать сбор всех типов логов на один сервер.

logger -P 514 -h logger.domain.ru 'Hello World'

По умолчанию logger пишет все сообщения в facility user с приоритетом notice, но это можно поменять используя ключ -p:

logger -p cron.warning 'Hello world'

dd if=/dev/zero of=/data/bigfile count=1024 bs=1024k

Получим файл размером в 1GB, причем dd честно 1024 раза запишет нули блоками по 1МБ. С 1Гб можно и потерпеть, но как быть с 10ГБ или 100ГБ? Ждать долго, да и диски жалко. Есть более быстрый и простой способ – опция seek. Смысл ее в том, что запись dd начнет только после нахождения определенного номера блока с начала вывода из if. Если я правильно понимаю физику процесса, то происходит это так: dd создает файл, ждет пока пройдет N блоков, указанных в seek, после чего начинает записывать блоки, указанные в count. Получается “пустой” файл большого размера.

dd if=/dev/zero of=/data/bigfile count=1 bs=1024k seek=`expr 1024 * 10`

Мгновенно получаем файл, размером в 10ГБ!

# Load other user-defined modules
for file in /etc/sysconfig/modules/*.modules ; do
  [ -x $file ] && $file
done

Т.е. для добавления модуля достаточно создать файл some_name.modules в каталоге /etc/sysconfig/modules/, внутри которого будет команда на его загрузку. Что-то такое:

# cat /etc/sysconfig/modules/some_name.modules
modprobe some_module

Попробуем автоматизировать процесс добавления/удаление/просмотра модулей, для этого пишем скрипт:

#!/bin/sh

check_action ()
{
        if [ $ACTION != "list" ] && [ $ACTION != "add" ] && [ $ACTION != "del" ]; then
                show_help
                exit 1
        fi
}

show_help ()
{
        echo Usage: `basename $0` ACTION [ MODULE_NAME ]
        echo ACTION - list\|add\|del
        echo MODULE_NAME - module name for add\|del ACTION
}

make_action ()
{
        case $ACTION in
                "list")
                        for i in `find $WORKDIR -type f -name "*.modules"`; do
                                module=`echo $i|sed 's/\.modules//'`
                                echo `basename $module`
                        done
                ;;
                "add")
                        echo "modprobe $MODULE_NAME" > $WORKDIR/$MODULE_NAME.modules
                        chmod 750 $WORKDIR/$MODULE_NAME.modules
                ;;
                "del")
                        rm -f $WORKDIR/$MODULE_NAME.modules
                ;;

        esac
}

ACTION="$1"
MODULE_NAME="$2"
WORKDIR="/etc/sysconfig/modules/"
: ${ACTION:="list"}

check_action
make_action

# wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
# wget http://centos.alt.ru/repository/centos/5/i386/centalt-release-5-3.noarch.rpm
# rpm -iv epel-release-5-3.noarch.rpm
# rpm -iv centalt-release-5-3.noarch.rpm
# yum check-update

Если у вас x86_64 архитектура, то просто смените i386 на x86_64 в ссылках.
Теперь можно поставить модуль ядра и утилиту ipset, после проверяем все ли работает:

# yum install kmod-ipset.i688 ipset.i386
# modprobe ip_set
# lsmod | fgrep ip_set
ip_set                 23708  0
# ipset -V
ipset v2.5.0 Protocol version 2.
# iptables -m set -h
iptables v1.3.5: Couldn't load match `set':/lib/iptables/libipt_set.so: cannot open shared object file: No such file or directory

Try `iptables -h' or 'iptables --help' for more information.

Не все так гладко, как хотелось бы! Модуль и утилита ipset есть, а iptables не может с ней работать. Дело в версии iptables, нужна версия старше 1.4, но в CentOS ее нет. Так что придется все же пойти на определенные жертвы. Будем ставить iptables из сорцов. Сносим “родной” iptables и ставим более новую версию. Перед этим добавляем в систему gcc, если еще нет:

# cp /etc/init.d/iptables /root/
# yum erase iptables
# yum install gcc
# cd /usr/src/
# wget http://www.netfilter.org/projects/iptables/files/iptables-1.4.7.tar.bz2
# tar xjf iptables-1.4.7.tar.bz2
# cd iptables-1.4.7
# ./configure
# make
# make install
# hash -r

Создаем тестовую таблицу и проверяем, что все работает:

# ipset -N badip iphash
# ipset -A badip 10.10.1.10
# iptables -A INPUT -p icmp -m set --set badip src -j DROP
# iptables -vL
Chain INPUT (policy ACCEPT 24372 packets, 2261K bytes)
 pkts bytes target     prot opt in     out     source               destination
    4   240 DROP       icmp --  any    any     anywhere             anywhere            match-set badip src

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 489 packets, 45302 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain RH-Firewall-1-INPUT (0 references)
 pkts bytes target     prot opt in     out     source               destination

Теперь про ложку дегтя, как же без нее. После удаления родного iptables и установки нового произошло несколько неприятных событий:
1) По умолчанию iptables из сорцов ставится в /usr/local/sbin/iptables, в родной был в /sbin/iptables. В принципе не проблема пересобрать нужными опциями (внимательно смотрим ./configure –help)
2) При удалении родного iptables, удаляется и /etc/init.d/iptables, так что я его я специально сохранил
3) Удаляется несколько полезный утилит типа iptstate
4) Все эти суммарные изменения могут где-нибудь неожиданно вылезти, так что перед вводом сервера в продакшен нужно очень хорошо все проверить.

UPDATE!!!
В репозитории CentAlt есть обновление для iptables с поддержкой ipset, так что достаточно

# yum update iptables

чтобы все заработало!

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

Особенно интересны главы о написании собственных TCP серверов. Очень подробно и на пальцах рассказывается про основные подходы к обработке нескольких одновременных клиентских запросов: fork, prefork, потоковый и мультиплексный. Причем дается не только пример кода, но и хорошая теоретическая база.

Ссылка на OZON:
Разработка сетевых программ на Perl