Расширенное использование Auditd для высокопроизводительных серверов Linux
Это перевод оригинальной статьи Auditd Advanced Usage for High Performance Linux Servers.
Подписывайтесь на телеграм-канал usr_bin, где я публикую много полезного по Linux, в том числе ссылки на статьи в этом блоге.
Примеры кода
В этом примере отслеживаются ключевые каталоги и файлы в узле Kubernetes на предмет любых событий записи, изменения атрибутов или выполнения, которые являются явными признаками потенциальной компрометации или неправильной настройки.
# Kubernetes Node Critical File Integrity Monitoring -w /etc/kubernetes/manifests -p wa -k k8s_manifest_integrity -w /etc/kubernetes/pki -p wa -k k8s_pki_integrity -w /var/lib/kubelet -p wa -k kubelet_data_integrity -w /usr/local/bin/kubelet -p wa -k kubelet_binary_integrity -a always,exit -F arch=b64 -S openat -F a2&O_CREAT -F dir=/var/lib/docker -k docker_container_creation
Эта конфигурация отслеживает изменения в манифестах Kubernetes, PKI, данных Kubelet и бинарных файлах, а также создание новых файлов в каталоге данных Docker, предоставляя важную информацию о безопасности времени выполнения контейнера.
Для обнаружения попыток повышения привилегий или несанкционированного доступа root важен мониторинг определённых системных вызовов. Это правило отслеживает попытки использования setuid, setgid или execve в несанкционированных исполняемых файлах, что может быть признаком вредоносной активности.
# Privilege Escalation Syscall Monitoring -a always,exit -F arch=b64 -S setuid -S setgid -k priv_escalation -a always,exit -F arch=b64 -S execve -F a0=/usr/bin/sudo -k sudo_usage -a always,exit -F arch=b64 -S execve -F a0=/usr/bin/su -k su_usage -a always,exit -F path=/bin/chmod -F perm=x -F success=0 -k chmod_failure
Эти правила фиксируют критические системные вызовы, связанные с изменениями привилегий и неудачными попытками выполнения chmod, предоставляя немедленные индикаторы компрометации (IOC).
Эффективный анализ логов auditd важен для использования огромного объёма генерируемых данных. Скрипт на Python может автоматизировать этот процесс, извлекая релевантную информацию и передавая её в SIEM. Этот скрипт демонстрирует базовые возможности анализа для определения определённых типов событий.
import subprocess
import json
import re
def parse_audit_logs(keyword=None):
cmd = ["ausearch", "-i", "-ts", "recent", "-m", "SYSCALL", "--raw"]
if keyword:
cmd.extend(["-k", keyword])
try:
output = subprocess.check_output(cmd, universal_newlines=True)
events = output.strip().split("----")
parsed_data = []
for event_block in events:
if not event_block.strip():
continue
event = {}
lines = event_block.strip().split("\n")
for line in lines:
match = re.match(r"type=(\w+)\s+(.*)", line)
if match:
event_type = match.group(1)
details = match.group(2)
event[event_type] = {
k: v.strip('"') for k, v in re.findall(r'(\w+)=(".*?"|\S+)', details)
}
if event:
parsed_data.append(event)
return parsed_data
except subprocess.CalledProcessError as e:
print(f"Error executing ausearch: {e}")
return []
if __name__ == "__main__":
# Example: Parse logs related to Kubernetes manifest integrity
k8s_events = parse_audit_logs(keyword="k8s_manifest_integrity")
print(json.dumps(k8s_events, indent=2))Этот скрипт Python используется ausearch для программного извлечения и анализа событий auditd, демонстрируя, как извлекать и обрабатывать определенные записи, связанные с безопасностью, для интеграции с платформами observability или пользовательскими системами оповещения.
Для Docker и container security, auditd выступает в качестве важной защиты на уровне хоста. Эти правила отслеживают действия демона docker и попытки изменения среды выполнения контейнера.
# Docker Host Security Monitoring -w /usr/bin/docker -p x -k docker_exec -w /var/lib/docker/overlay2 -p wa -k docker_storage_changes -a always,exit -F arch=b64 -S kill -F ppid=/usr/bin/dockerd -k docker_kill_attempts -a always,exit -F arch=b64 -S mount -F dir=/var/lib/docker -k docker_mount_activity
Эти правила отслеживают выполнение бинарного файла docker, изменения в уровнях хранения контейнера, а также любые действия по монтированию или сигналы завершения, направленные на процессы Docker, предоставляя информацию о потенциальных попытках выхода из контейнера или несанкционированных операциях Docker.
Наконец, обеспечение согласованного применения правил auditd на всех серверах в рамках парадигмы infrastructure as code имеет решающее значение. Этот фрагмент Terraform для auditd, иллюстрирует, как инструмент управления конфигурацией может обеспечить наличие файла правил. На практике для развертывания файлов правил auditd часто используются инструменты управления конфигурацией Ansible или Chef.
# Example: Deploying auditd rules via user_data for EC2 instances
# (Note: For real-world, prefer configuration management like Ansible/Chef)
resource "aws_instance" "auditd_server" {
# ... other instance configuration ...
user_data = <<-EOF
#!/bin/bash
echo "# Custom auditd rules for high-performance servers" > /etc/audit/rules.d/99-custom.rules
echo "-w /etc/kubernetes -p wa -k k8s_config_change" >> /etc/audit/rules.d/99-custom.rules
echo "-a always,exit -F arch=b64 -S openat -F a2&O_CREAT -F dir=/var/lib/docker -k docker_container_creation" >> /etc/audit/rules.d/99-custom.rules
auditctl -R /etc/audit/rules.d/99-custom.rules
systemctl restart auditd
EOF
}Здесь демонстрируется подготовка экземпляра EC2 со встроенными правилами auditd через user_data, рудиментарную форму infrastructure as code, которая обеспечивает настройку auditd с момента запуска экземпляра.
Лучшие практики
Такие инструменты, как Fluentd или rsyslog, могут пересылать события auditd в Elasticsearch, Splunk или Kafka, обеспечивая корреляцию в режиме реального времени с другими телеметрическими данными безопасности и упрощая расширенную аналитику. Этот централизованный подход поддерживает проактивный поиск угроз и упрощает составление отчётов о соответствии требованиям, предоставляя агрегированное представление событий безопасности в рамках распределённой архитектуры.
# Example: Configuring rsyslog to forward auditd logs to a remote SIEM
# Add this to /etc/rsyslog.d/auditd.conf
$ModLoad imfile
$InputFileName /var/log/audit/audit.log
$InputFileTag auditd_log:
$InputFileStateFile audittag-state
$InputFileSeverity info
$InputFileFacility local6
$InputRunFileMonitor
# Define template for JSON output
template(name="json_auditd" type="list") {
constant(value="{")
property(name="timereported" format="jsonf")
constant(value=",")
property(name="hostname" format="jsonf")
constant(value=",")
property(name="syslogseveritytext" format="jsonf")
constant(value=",")
property(name="msg" format="jsonf")
constant(value="}")
}
# Forward to SIEM using TCP
local6.* @siem.example.com:514;json_auditdВ этом фрагменте конфигурации rsyslog показано, как анализировать журналы auditd и пересылать их в виде структурированного JSON в удаленную SIEM, что повышает удобство приема данных и аналитические возможности.
Для container runtime security auditdслужит важной защитой на уровне хоста. Инструменты container runtime security обеспечивают изоляцию и анализ поведения внутри контейнеров, а также auditd контролирует активность ядра хоста и демонов, которая может указывать на выход из контейнера, повышение привилегий или несанкционированное манипулирование образами или средами выполнения контейнеров. Эта многоуровневая защита критически важна в динамичной среде Kubernetes orchestration.
# Example: Python script for basic auditd log anomaly detection
import json
import time
from collections import deque
# Simplified thresholding for demonstration
ALERT_THRESHOLD = 5 # Number of suspicious events in a short period
# In-memory storage for recent events
recent_events = deque()
last_alert_time = 0
def process_audit_event(event_data):
global last_alert_time
# Simulate receiving a parsed audit event
event = json.loads(event_data)
# Basic anomaly: detect multiple failed privilege escalation attempts
if "SYSCALL" in event and event["SYSCALL"].get("key") in ["priv_escalation", "sudo_usage", "su_usage"] and event["SYSCALL"].get("success") == "no":
timestamp = time.time()
recent_events.append((timestamp, event))
# Clean old events
while recent_events and recent_events[0][0] < timestamp - 60: # Last 60 seconds
recent_events.popleft()
if len(recent_events) >= ALERT_THRESHOLD:
if timestamp - last_alert_time > 300: # Throttle alerts to every 5 minutes
print(f"*ALERT: High rate of suspicious privilege attempts detected! Events: {len(recent_events)}*")
# In a real system, send to PagerDuty/Slack/Email
last_alert_time = timestamp
if __name__ == "__main__":
# Simulate receiving audit events
mock_events = [
'{"SYSCALL": {"key": "priv_escalation", "success": "no", "pid": "1234"}}',
'{"SYSCALL": {"key": "priv_escalation", "success": "no", "pid": "1235"}}',
'{"SYSCALL": {"key": "sudo_usage", "success": "no", "pid": "1236"}}',
'{"SYSCALL": {"key": "priv_escalation", "success": "yes", "pid": "1237"}}', # A successful one
'{"SYSCALL": {"key": "priv_escalation", "success": "no", "pid": "1238"}}',
'{"SYSCALL": {"key": "priv_escalation", "success": "no", "pid": "1239"}}',
'{"SYSCALL": {"key": "sudo_usage", "success": "no", "pid": "1240"}}',
]
for i, event_str in enumerate(mock_events):
process_audit_event(event_str)
if i == 3: time.sleep(5) # Simulate a slight delayЭтот скрипт Python выполняет простое обнаружение аномалий событий auditd в оперативной памяти, демонстрируя, как можно применять пользовательскую логику для выявления подозрительных закономерностей в режиме реального времени.
Наконец, для обеспечения соответствия нормативным требованиям записи auditd предоставляют неопровержимое доказательство действий системы. Ведение комплексных, защищенных от несанкционированного доступа журналов аудита крайне важно для подтверждения соответствия таким стандартам, как PCI DSS, HIPAA или SOC 2. Правила auditd можно явно сопоставить с требованиями соответствия, гарантируя регистрацию и надежное долгосрочное хранение всех необходимых событий.
На этом все! Спасибо за внимание! Если статья была интересна, подпишитесь на телеграм-канал usr_bin, где будет еще больше полезной информации.