Всем интересующимся программированием на java: проводятся курсы, доп. информация по ссылке. Автор курса мой знакомый - Лигай Виталий, гуру программирования, как я считаю.
четверг, 26 февраля 2015 г.
понедельник, 23 февраля 2015 г.
Отказоустойчивый, масштабируемый кластер приложения с балансировкой нагрузки, часть 1
Заголовок броский, я бы даже сказал, слегка желтоват (желтая IT пресса - более унылой вещи трудно представить). Но, тем не менее, это правда, хотя, как известно, все скрывается в деталях. В данном случае детали - это, собственно, возможность самого ПО делить нагрузку или обеспечивать отказоустойчивость. Но хватит лирики, перейдем к постановке задачи.
Мне нужен почтовый релей, забегая вперед, скажу, что с таким же успехом это может быть любое другое приложение, например, web сервер. Могу показаться банальным занудой, но хочу еще раз повторить: каждый сервис требует отдельного анализа, и не факт, что желаемое удастся реализовать. Далее отразим заголовок статьи: релей должен быть отказоустойчивым и иметь возможность масштабирования. Читатель статьи может возразить, что для почтового релея все вышесказанное можно реализовать, добавив несколько MX записей в доменной зоне. К сожалению, я ограничен одним, уже существующим ip адресом релея, таким образом, вариант с MX не годится. Подведем итог: нужно несколько почтовых релеев, обеспечивающих отказоустойчивость сервиса, разделяющих нагрузку и использующих один ip адрес.
В плане выбора ПО все просто и традиционно - я буду использовать дистрибутив oracle linux 7 (почти аналогичны ему centos 7 или rhel 7), в качестве smtp сервиса - postfix. Для балансировки будет использоваться решение LVS, поскольку ее частью является подсистема linux ядра - ipvs, быстрый и надежный вариант балансировки трафика на 4-м уровне сетевой модели OSI.
Оставшиеся вводные данные:
Используемая сеть: 192.168.3.0/24
IP серверов по порядку: 192.168.3.[101-105]
Обычно в стандартной практике делают отдельный кластер балансировки и группу серверов приложения, к примеру, рекомендуемое решение от Red Hat. Особенность данной реализации заключается в том, что каждый сервер является сервером приложения и балансировщиком трафика одновременно. Один из балансировщиков является активным, остальные резервные. В моем случае используются четыре релея, расположенные по два в двух географически разнесенных ЦОДах. Ниже приведен рисунок, иллюстрирующий прохождение трафика в кластере, к которому мы будем возвращаться при описании процесса работы.
Посмотрите, что происходит: входящее соединение попадает на активную ноду (кластерный mac не используется), активная нода в соответствии с правилами балансировки обрабатывает соединение самостоятельно или передает его на одну из соседних нод, т.е. в обработке принимают участие все ноды кластера, затем нода отвечает клиенту. Таким образом весь входящий трафик проходит через одну активную ноду, а соответствующий исходящий трафик отправляется напрямую клиенту.
Перейдем к установке и настройке. Все написанное ниже справедливо для всех нод кластера, если не указано обратное. Установку и настройку postfix рассматривать не будем, убедитесь только что postfix использует все доступные сетевые интерфейсы:
# grep "inet_interfaces" /etc/postfix/main.cf | grep -v "^#"
inet_interfaces = all
Отключим firewalld, его можно будет настроить позднее, после того как будете твердо уверены, что кластер функционирует должным образом:
# systemctl disable firewalld.service
# systemctl stop firewalld.service
Установим keepalived, ipvsadm и модуль python ipaddr, модуль нужен для скрипта:
# yum -y install keepalived ipvsadm python-ipaddr
Разберем конфигурационный файл keepalived:
# Секция определения общих параметров
global_defs {
notification_email {
# Список почтовых адресов, по которым будут приходить оповещения о
# недоступности нод или сервисов
unix_adm@domain.ru
}
# Email от которого будет рассылаться почта
notification_email_from keepalived@domain.ru
# Адрес smtp сервера и время, в течение которого будет производится попытка
# отправки почты
smtp_server 192.168.3.1
smtp_connect_timeout 30
# Идентификатор сервера
router_id server01.domain.ru
}
# Секция описания экземпляров VRRP (перемещаемые IP)
vrrp_instance mail_relay {
# Начальное состояние при запуске, на остальных серверах должно быть BACKUP
state MASTER
# Интерфейс, на котором будет работать экземпляр VRRP
interface eth0
# Идентификатор экземпляра VRRP, должен быть идентичен на всех нодах.
virtual_router_id 11
# Приоритет при выборе MASTER'а, нода с большим приоритетом становится
# активной.
priority 100
# Интервал уведомлений о состоянии, которые рассылает MASTER нода.
# При отсутствии уведомлений произойдут перевыборы.
advert_int 2
# Секция аутентификации, пароль должен быть идентичен на всех нодах,
# используется первые 8 символов.
authentication {
auth_type PASS
auth_pass mrelay
}
# Список адресов, которые будут добавлены на ноду при выборе ее MASTER
virtual_ipaddress {
192.168.3.100
}
# Произвести миграцию состояния MASTER при появлении ноды с более высоким
# приоритетом. В случае установки опции в nopreempt при появлении ноды с
# более высоким приоритетом MASTER нодой останется прежняя нода.
preempt
# Скрипт, который надо выполнить при событии, когда нода становится MASTER
notify_master "/etc/keepalived/bypass_ipvs.py -r 192.168.3.100"
# Скрипт, который надо выполнить при событии, когда нода становится SLAVE
notify_backup "/etc/keepalived/bypass_ipvs.py -a 192.168.3.100"
# Скрипт, который надо выполнить при событии ошибки смены роли ноды
notify_fault "/etc/keepalived/bypass_ipvs.py -a 192.168.3.100"
}
Что выполняет скрипт: при установке состояния BACKUP на ноде он добавляет правило в iptables, которое заменяет (NAT) общий IP в пакетах входящего трафика на локальный IP ноды, и наоборот - для ответного трафика:
-A PREROUTING -t nat -d 192.168.3.100/32 -p tcp -j REDIRECT
Таким образом реализуется совместная обработка трафика всеми нодами, посмотрите еще раз рисунок вверху. В случае, когда нода становится MASTER, скрипт убирает правило натирования, поскольку общий IP принадлежит этой ноде. Скачать скрипт можно здесь.
Несколько замечаний:
- state - если вы уверены в качестве сети, можно на всех нодах кластера выставить BACKUP, в этом случае мастер определится в результате выборов.
- priority - в случае равных приоритетов побеждает нода с большим IP.
- nopreempt - при данной опции state должен быть установлен в BACKUP.
- если установить опции state BACKUP, одинаковый priority и nopreempt на все ноды, мы получим идентичный конфигурационный файл, что очень удобно в системах централизованного сопровождения серверов. Но вместе с тем шансы возникновения ситуации "split brain" в результате каких либо проблем также увеличиваются.
# Секция конфигурации политики балансировки (LVS) и описание серверов приложения
virtual_server 192.168.3.100 25 {
# Период опроса серверов приложения
delay_loop 2
# Планировщик балансировки, wlc - Weighted Least-Connections Scheduling.
lb_algo wlc
# Метод передачи пакетов на сервера приложений, dr - Direct Routing
lb_kind DR
protocol TCP
# Секция описание сервера приложения 192.168.3.101
real_server 192.168.3.101 25 {
# Вес сервера
weight 1
# Секция проверки доступности приложения, в данном случае выполняется
# проверка доступности smtp приложения.
SMTP_CHECK {
connect_timeout 5
retry 3
# Имя в команде smtp helo
helo_name smtpchecker.domain.ru
}
}
# Далее однотипные описания серверов для 192.168.3.102 и т.д.
}
Еще несколько замечаний:
- lb_algo wlc - распределяет большее количество запросов серверам с наименьшим количеством активных подключений в соответствии с их весом.
- lb_kind DR - маршрутизация пакета, в этом случае пакет с активной ноды передается на резервную следующим образом: производится замена MAC адреса в поле destination MAC в ethernet заголовке пакета с MAC адреса активной ноды на MAC адрес сервера приложения. IP адрес остается без изменения. В свою очередь сервер приложения (нода в состоянии BACKUP) получив пакет, натирует общий IP адрес в поле destination IP в свой собственный.
- со всеми вариантами балансировки, передачи пакетов, методах проверки доступности приложения можно ознакомиться на сайте проекта LVS.
Запустим keepalived и проверим что получилось:
# systemctl enable keepalived.service
# systemctl start keepalived.service
$ telnet 192.168.3.100 25
Trying 192.168.3.100...
Connected to 192.168.3.100.
Escape character is '^]'.
220 server01.domain.ru ESMTP Postfix
quit
221 2.0.0 Bye
Connection closed by foreign host.
[valentine@server ~]$ telnet 192.168.3.100 25
Trying 192.168.3.100...
Connected to 192.168.3.100.
Escape character is '^]'.
220 server02.domain.ru ESMTP Postfix
quit
221 2.0.0 Bye
Connection closed by foreign host.
Посмотреть логи keepalived:
# journalctl -u keepalived.service
Посмотреть, на какой ноде находится общий IP, привычная команда ifconfig его не показывает:
# ip addr show
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 52:54:00:0d:5a:1a brd ff:ff:ff:ff:ff:ff
inet 192.168.3.101/24 brd 192.168.3.255 scope global dynamic eth0
valid_lft 70403sec preferred_lft 70403sec
inet 192.168.3.100/32 scope global eth0
...
Или более современный вариант:
# nmcli device show eth0
...
IP4.ADDRESS[1]: ip = 192.168.3.101/24, gw = 192.168.3.1
IP4.ADDRESS[2]: ip = 192.168.3.100/32, gw = 192.168.3.1
...
Посмотреть статистику балансировки:
# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.3.100:25 wlc
-> 192.168.3.101:25 Route 1 2 14
-> 192.168.3.102:25 Route 1 3 9
...
Посмотреть текущие соединения:
# ipvsadm -Lnc
IPVS connection entries
pro expire state source virtual destination
TCP 13:20 ESTABLISHED 192.168.3.3:59527 192.168.3.100:25 192.168.3.102:25
...
Если в сети несколько vrrp экземпляров, можно проверить номера идентификаторов
# tcpdump -nnn ip proto 112
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:11:36.244824 IP 192.168.3.101 > 224.0.0.18: VRRPv2, Advertisement, vrid 11, prio 100, authtype simple, intvl 1s, length 20
Удачных внедрений!
Upd: продолжение, для тех кому мало будет 4 ноды.
воскресенье, 22 февраля 2015 г.
Настройка соединения мост для использования в Virtual Machine Manager
Коллеги, читатели, сегодня мне понадобилось провести эксперимент с несколькими виртуальными машинами на домашнем PC. Для эксперимента надо было пустить машины напрямую в локальную сеть. Сделать это можно путем создания сетевого моста (бридж), в котором будут находится интерфейсы виртуальных машин и интерфейс гипервизора, в литературе этот вариант настройки также называется "shared physical device"
Несмотря на то, что, начиная с Fedora 20 (у меня Fedora 21) NetworkManager поддерживает создание соединений типа мост, выполнять будем по старинке (я не всегда понимаю логику работы NetworkManager, и собственно, попробовав с наскоку настроить, я получил неудовлетворительный результат).
Создайте конфигурационный файл сетевого моста:
# cat /etc/sysconfig/network-scripts/ifcfg-bridge0
DEVICE=bridge0
ONBOOT=yes
TYPE=Bridge
BOOTPROTO=dhcp
NM_CONTROLLED=no
DELAY=0
где bridge0 это имя моста.
Соответствующая конфигурация сетевого интерфейса гипервизора:
# cat /etc/sysconfig/network-scripts/ifcfg-eno1
TYPE=Ethernet
ONBOOT=yes
HWADDR=91:DE:80:B4:5F:0C
DEVICE=eno1
BOOTPROTO=none
NM_CONTROLLED=no
BRIDGE=bridge0
Удалите конфигурацию NetworkManadger, относящуюся к физическому интерфейсу. Далее можете перегрузиться или перезапустить network.service. Перейдем к настройке в Virtual Machine Manager. Зайдите в параметры оборудования виртуальной машины, выберите "Указать имя общего устройства" и соответственно укажите имя сетевого моста, как на рисунке ниже
воскресенье, 19 октября 2014 г.
Поиск установленных сторонних rpm пакетов
На серверах, доставшихся в наследство, полезно определить наличие "левых" пакетов. Это можно сделать следующим образом:
Теперь самое время выяснить, с какими флагами компиляции собрано:
$ rpm -qa --qf "%{NAME} - \"%{OPTFLAGS}\"\n" nginx
nginx - "-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic"
Если потребуется выяснять дальше, могут пригодится другие теги в запросе:
$ rpm --querytags
$ rpm -qa --qf "%{NAME} - %{VENDOR}\n"
Теперь самое время выяснить, с какими флагами компиляции собрано:
$ rpm -qa --qf "%{NAME} - \"%{OPTFLAGS}\"\n" nginx
nginx - "-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic"
Если потребуется выяснять дальше, могут пригодится другие теги в запросе:
$ rpm --querytags
Удивляет, почему всякий раз, приходя на новое место работы, приходится разгребать авгиевы конюшни и перевоспитывать IT братию.
понедельник, 9 июня 2014 г.
"Полувысокая" доступность сервиса
Столкнулся со следующей задачей: есть два сервера с развернутым на них СУБД Oracle, один из серверов основной рабочий, второй, соответственно, резервный, операционная система - oel 6. При смене ролей серверов (не буду рассказывать о методе резервирования и процедуре смены, поскольку к теме заметки это не относится), основной становится резервным и наоборот. Все хорошо, но как нетрудно догадаться, на клиентах придется менять IP адрес подключения, что может доставить определенные трудности и затраты времени. Реализовывать варианты HA для IP адреса поздновато, т.к. все работает и времени простоя на внедрение и отладку нет, и просто не имеет смысла т.к. смена ролей серверов производится вручную. В таком случае, напрашивается сразу решение - вынести ip подключения как alias на сетевой интерфейс и переносить его при смене ролей. Это просто, логично, но есть следующая трудность - при переносе IP адреса меняется физический интерфейс и, как следствие, MAC адрес. Таким образом, для того чтобы пакеты пошли на новый интерфейс, необходимо у каждого клиента обновить ARP запись для этого IP адреса. Это можно сделать с помощью пакета ARP оповещения, т.е. сервер, на который "переехал" IP адрес должен отправить широковещательный пакет c новым IP и с mac адресом своего интерфейса. Это можно реализовать с помощью утилиты send_arp. Man страничка для нее несколько запутанно написана, поэтому немного о том, как ее использовать.
send_arp [-i dev] src_ip_addr src_hw_addr targ_ip_addr tar_hw_addr
Итого, допустим, что переносимый IP - 192.168.10.10, интерфейс eth2 и MAC этого интерфейса - 94:de:82:a8:4f:0c, тогда:
send_arp -i eth2 192.168.10.10 94:de:82:a8:4f:0c 192.168.10.10 ffffffffffff
Непонятно почему такие targ_ip_addr и tar_hw_addr? IP адрес назначения, в пакете анонсирования должен быть идентичен IP источника, см RFC 3927. MAC адрес назначения должен быть широковещательным.
Где взять саму утилиту? Она входит в состав пакета piranha, естественно, нет смысла ставить сам пакет и зависимости. Ставим:
# yum install yum-plugin-downloadonly
# yum --downloadonly install piranha
# rpm2cpio /var/cache/yum/x86_64/6Server/public_ol6_latest/packages/piranha-0.8.6-4.0.1.el6.x86_64.rpm | cpio -iumd ./usr/sbin/send_arp
# mv usr/sbin/send_arp /usr/sbin/
Можно уже пользоваться, а можно написать небольшой скрипт, для удобства использования. Входные данные для скрипта - имя alias'а, а так же IP адрес и сетевая маска. Разместим эти данные в файле:
send_arp [-i dev] src_ip_addr src_hw_addr targ_ip_addr tar_hw_addr
Итого, допустим, что переносимый IP - 192.168.10.10, интерфейс eth2 и MAC этого интерфейса - 94:de:82:a8:4f:0c, тогда:
send_arp -i eth2 192.168.10.10 94:de:82:a8:4f:0c 192.168.10.10 ffffffffffff
Непонятно почему такие targ_ip_addr и tar_hw_addr? IP адрес назначения, в пакете анонсирования должен быть идентичен IP источника, см RFC 3927. MAC адрес назначения должен быть широковещательным.
Где взять саму утилиту? Она входит в состав пакета piranha, естественно, нет смысла ставить сам пакет и зависимости. Ставим:
# yum install yum-plugin-downloadonly
# yum --downloadonly install piranha
# rpm2cpio /var/cache/yum/x86_64/6Server/public_ol6_latest/packages/piranha-0.8.6-4.0.1.el6.x86_64.rpm | cpio -iumd ./usr/sbin/send_arp
# mv usr/sbin/send_arp /usr/sbin/
Можно уже пользоваться, а можно написать небольшой скрипт, для удобства использования. Входные данные для скрипта - имя alias'а, а так же IP адрес и сетевая маска. Разместим эти данные в файле:
# cat /etc/ipalias.conf
alias_name=eth2:1
alias_ip=192.168.10.10
alias_netmask=255.255.255.0
Собственно сам скрипт:
# cat /usr/local/bin/ipalias.sh
#!/bin/bash
export PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
. /etc/ipalias.conf
interface_name=`echo $alias_name | awk -F: '{ print $1 }'`
new_mac=`ifconfig $interface_name | grep HWaddr | awk -FHWaddr '{ print $2 }'`
case "$1" in
up)
#Up alias
ping -c 1 $alias_ip > /dev/null 2>&1
OUT=$?
if [ "$OUT" == "0" ]
then
echo "ERROR! IP $alias_ip is exist"
exit 1
else
ifconfig $alias_name $alias_ip netmask $alias_netmask
send_arp -i $interface_name $alias_ip $new_mac $alias_ip ffffffffffff
fi
;;
down)
#Down alias
ifconfig -a | grep $alias_name > /dev/null 2>&1
OUT=$?
if [ "$OUT" != "0" ]
then
echo "ERROR! Interface $alias_name is not exist"
exit 1
else
ifconfig $alias_name down
fi
;;
*)
echo
echo "Usage:"
echo "$0 up"
echo " or"
echo "$0 down"
echo
echo "/etc/ipalias.conf - Configuration file"
echo
;;
esac
воскресенье, 7 июля 2013 г.
Возможность чтения лог файлов пользователем отличным от root
Бывают случаи, когда нужно пользователю, не обладающему привилегиями root, дать возможность читать системные логи. В случае использования rsyslog, это легко сделать, предоставив определенной группе, в которую входит пользователь, право на чтение лог файлов. Для смены группы владельца всех журналов необходимо добавить в конфигурацию /etc/rsyslog.conf следующие директивы (точно работает в rhel\centos 6, версия rsyslog 5.8.10):
Если вы пользуетесь более новой версией rsyslog, чем в rhel\centos 6 (например, которая поставляется в fedora 18 - rsyslog 7.2.6), можно воспользоватся более изящным способом - через action. К примеру, для того, чтобы лог файл messages имел группу владельца wheel:
*.info;mail.none;authpriv.none;cron.none action(type="omfile" FileCreateMode="0644" FileGroup="wheel" File="/var/log/messages")
$umask 0000
$FileGroup some_group
$FileCreateMode 0640
Если вы пользуетесь более новой версией rsyslog, чем в rhel\centos 6 (например, которая поставляется в fedora 18 - rsyslog 7.2.6), можно воспользоватся более изящным способом - через action. К примеру, для того, чтобы лог файл messages имел группу владельца wheel:
*.info;mail.none;authpriv.none;cron.none action(type="omfile" FileCreateMode="0644" FileGroup="wheel" File="/var/log/messages")
вторник, 11 июня 2013 г.
Аудит в Linux
Обычно об аудите задумываются когда возникают подозрения в компрометации системы. Лично я использовал аудит несколько раз за свою практику. И каждый раз я быстренько смотрел одним глазочком, как его настроить. Как правило это был аудит модификаций файлов. В данной статье я не преследую цель раскрыть архитектурные подробности устройства аудита в linux, или дать рекомендации по настройке/администрированию для сред CC-CAPP/EAL (Common Criteria-Controlled Access Protection Profiles/Evaluation Assurance Level), это скорее практическая статья. Хотя минимум теоретической информации все же необходим. Все ниже написанное справедливо для rhel6, расхождения с другими дистрибутивами не существенное.
Подсистема аудита состоит из нескольких компонентов:
Используемые конфигурационные файлы:
Настройка даемона auditd.
Как отмечено выше, настройка сводится к изменению параметров в файлах конфигурации /etc/sysconfig/auditd и /etc/audit/auditd.conf. Поверьте мне на слово, файл /etc/sysconfig/auditd с содержимым по умолчанию можно не трогать, там ничего интересного нет. Разберем лучше сразу второй файл - /etc/audit/auditd.conf.
# cat /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log
log_format = RAW
log_group = root
priority_boost = 4
flush = INCREMENTAL
freq = 20
num_logs = 5
disp_qos = lossy
dispatcher = /sbin/audispd
name_format = NONE
##name = mydomain
max_log_file = 6
max_log_file_action = ROTATE
space_left = 75
space_left_action = SYSLOG
action_mail_acct = root
admin_space_left = 50
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND
##tcp_listen_port =
tcp_listen_queue = 5
tcp_max_per_addr = 1
##tcp_client_ports = 1024-65535
tcp_client_max_idle = 0
enable_krb5 = no
krb5_principal = auditd
##krb5_key_file = /etc/audit/audit.key
Значения параметров:
Управление подсистемой аудита
Управление подсистемой аудита и добавление новых правил осуществляется утилитой — auditctl. Естественно эти изменения временные, для того что бы они стали постоянными их необходимо прописать в /etc/audit/audit.rules.
Основные команды управления auditctl:
Приведу несколько примеров:
Посмотрим как выглядит настройка по умолчанию даемона аудита:
# auditctl -s
AUDIT_STATUS: enabled=1 flag=1 pid=985 rate_limit=0 backlog_limit=320 lost=0 backlog=0
Удалим все существующие правила:
# auditctl -D
Увеличим размер буфера сообщений:
# auditctl -b 1024
Добавим правило аудита, оно включает протоколирование всех попыток изменить содержимое файла /etc/shadows или изменить его атрибуты, структуру правил рассмотрим позже:
# auditctl -w /etc/shadow -p wa
В файл /etc/audit/audit.rules параметры конфигурации и правила записывается точно в таком же виде, как и консольные команды, за исключением самой команды auditctl, т.е для вышеприведенных примеров будет справедливо:
# cat /etc/audit/audit.rules
-D
-b 1024
-w /etc/shadow -p wa
Подсистема аудита состоит из нескольких компонентов:
- модуль ядра — перехватывает системные вызовы (syscalls) и регистрирует событие;
- даемон auditd — пишет зарегистрированное событие на диск в файл;
- даемон audispd — осуществляет пересылку сообщений (диспетчер) к другому приложению;
- ряд вспомогательных утилит:
- auditctl — утилита управления демоном auditd;
- aureport — дает возможность составить отчет, отчет может быть настроен под задачи;
- ausearch — позволяет выбрать события по заданному критерию;
- autrace — утилита позволяет выполнить трассировку отдельного приложения.
Используемые конфигурационные файлы:
- /etc/sysconfig/auditd — содержит настройки используемые при старте даемона auditd;
- /etc/audit/auditd.conf — настройки поведения даемона auditd;
- /etc/audit/audit.rules — файл содержащий правил аудита.
Настройка даемона auditd.
Как отмечено выше, настройка сводится к изменению параметров в файлах конфигурации /etc/sysconfig/auditd и /etc/audit/auditd.conf. Поверьте мне на слово, файл /etc/sysconfig/auditd с содержимым по умолчанию можно не трогать, там ничего интересного нет. Разберем лучше сразу второй файл - /etc/audit/auditd.conf.
# cat /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log
log_format = RAW
log_group = root
priority_boost = 4
flush = INCREMENTAL
freq = 20
num_logs = 5
disp_qos = lossy
dispatcher = /sbin/audispd
name_format = NONE
##name = mydomain
max_log_file = 6
max_log_file_action = ROTATE
space_left = 75
space_left_action = SYSLOG
action_mail_acct = root
admin_space_left = 50
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND
##tcp_listen_port =
tcp_listen_queue = 5
tcp_max_per_addr = 1
##tcp_client_ports = 1024-65535
tcp_client_max_idle = 0
enable_krb5 = no
krb5_principal = auditd
##krb5_key_file = /etc/audit/audit.key
Значения параметров:
- log_file — место расположения и название файла аудита;
- log_format — формат ведения лога. Возможные значения: RAW — сообщения записываются в том виде как их передало ядро; nolog — не писать сообщения;
- log_group — группа-владелец лог-файла аудита;
- priority_boost — приоритет c каким работает даемон (nice).
- flush — как будет записываться лог-файл на диск. Возможные значения: none — не использовать политики записи, incremental — лог будет записываться с определенной периодичностью, определенной в параметре freq; data — данные пишутся в файл в синхронном режиме; sync — в синхронном режиме находятся не только данные но и метаданные файла.
- freq — число событий при котором осуществляется запись данных на диск, используется при значении flush = incremental.
- num_logs — число лог файлов аудита хранимых на диске, если настроена ротация в параметре max_log_file_action.
- disp_qos — определяет надежность передачи данных между даемоном auditd и диспетчером audispd. Возможные значения: lossy — auditd может не передавать некоторые события аудита, если очередь событий полна при этом события будут записаны на диск; lossless — логирование событий на диск будет остановлено пока не освободится место в очереди.
- dispatcher — где располагается исполняемый файл диспетчера.
- name_format и name. name_format — определяет порядок разрешения имен хостов. Возможные значения: none — имя не используется; hostname — имя возвращенное через запрос gethostname; fqd — полное имя хоста, возвращенное через DNS запрос; numeric — ip адрес; user — строка определенная в параметре name.
- max_log_file и max_log_file_action. max_log_file — максимальный размер лог файла в мегабайтах, по достижению которого будет выполнено действие определенное в max_log_file_action. Возможные действия: ignore — ничего не делать; syslog — отправить предупреждение в syslog; suspend — остановить запись событий на диск; rotate — произвести ротацию лог файлов в соответствии с числом num_logs; keep_logs — осуществить ротацию, при этом не удалять старые файлы.
- space_left, space_left_action и action_mail_acct. space_left — величина в мегабайтах, определяющая размер оставшегося дискового пространства при достижении которого будет выполнно действие space_left_action. Возможные действия: ignore — ничего не делать; syslog — отправить предупреждение в syslog; email — отправить письмо аккаунту определенному в action_mail_acct; exec — выполнить скрипт; suspend — остановить запись на диск, перевести систему в single mode; halt — выключить систему.
- admin_space_left и admin_space_left_action. admin_space_left — величина в мегабайтах оставшегося свободного пространства на диске. Последний шанс для администратора что бы добавить/очистить свободное пространство. Величина должна быть меньше чем space_left. Действия которые можно определить в admin_space_left_action аналогичны space_left_action.
- disk_full_action — действия выполняемые при заполнении всего дискового пространства, аналогичны space_left_action.
- disk_error_action — действия выполняемые при возникновении дисковой ошибки, аналогичны space_left_action.
- tcp_listen_port, tcp_listen_queue, tcp_max_per_addr, tcp_client_ports и tcp_client_max_idle — даемон аудита может принимать сообщения от других даемонов. Данные переменные определяют сетевые настройки.
- enable_krb5, krb5_principal, krb5_key_file — переменные определяющие аутентификацию по протоколу kerberos.
Управление подсистемой аудита
Управление подсистемой аудита и добавление новых правил осуществляется утилитой — auditctl. Естественно эти изменения временные, для того что бы они стали постоянными их необходимо прописать в /etc/audit/audit.rules.
Основные команды управления auditctl:
- -e [0..2] — (enabled), при 0 — отключить, 1 — включить, 2 — включить и заблокировать конфигурацию аудита. В случае блокировки изменение конфигурации аудита будет доступно только после перезагрузки хоста;
- -f [0..2] — (flag), установка поведения при критической ошибке, 1 — ничего не делать, 1 — вывести сообщение на консоль, 2 — немедленное выключение системы;
- -r — (rate_limit), лимит скорости сообщений в минуту, при 0 — скорость не лимитируется. Если будет осуществлено превышение — будет выполнено действие поведения при критической ошибке flag;
- -b — (backlog_limit), размер буфера сообщений ожидающих обработки. Если будет осуществлено превышение — будет выполнено действие поведения при критической ошибке flag;
- -s — запрос текущего состояние даемона аудита;
- -l — вывод всех текущих правил аудита;
- -D — очистить все правила аудита.
Приведу несколько примеров:
Посмотрим как выглядит настройка по умолчанию даемона аудита:
# auditctl -s
AUDIT_STATUS: enabled=1 flag=1 pid=985 rate_limit=0 backlog_limit=320 lost=0 backlog=0
Удалим все существующие правила:
# auditctl -D
Увеличим размер буфера сообщений:
# auditctl -b 1024
Добавим правило аудита, оно включает протоколирование всех попыток изменить содержимое файла /etc/shadows или изменить его атрибуты, структуру правил рассмотрим позже:
# auditctl -w /etc/shadow -p wa
В файл /etc/audit/audit.rules параметры конфигурации и правила записывается точно в таком же виде, как и консольные команды, за исключением самой команды auditctl, т.е для вышеприведенных примеров будет справедливо:
# cat /etc/audit/audit.rules
-D
-b 1024
-w /etc/shadow -p wa
Подписаться на:
Сообщения (Atom)