it-swarm-eu.dev

Jednoduchý příklad konfigurace auditd?

Auditd byl doporučen v odpovědi na Protokolování Linuxových příkazů?

Zdá se, že výchozí instalace na Ubuntu sotva něco zaznamenává. Existuje několik příkladů, které s tím přicházejí (capp.rules, nispom.rules, stig.rules), ale není jasné, jaký by byl dopad každého na výkon, ani na jaké prostředí nebo předpoklady by se každý nejlépe hodil.

Jaký by byl nejlepší výchozí bod pro nasazení auditu, řekněme, na webovém serveru? To bude zahrnovat soubor audit.rules, nastavení umožňující odesílání proudu protokolu auditu na vzdálený počítač v reálném čase a nejjednodušší nástroje pro zobrazení toho, co bylo zaznamenáno.

A co další typický stolní počítač?

Aktualizujte: dannysauer poznamenává, že pro bezpečnost je důležité začít s cílem, a já souhlasím. Ale mým hlavním záměrem je spark několik užitečnějších vysvětlení použití tohoto nástroje a vidět příklad pracoval o tom v akci, spolu s důsledky pro výkon a skladování atd. Pokud to již existuje a chybělo mi to, ukažte na něj. Pokud ne, navrhuji, aby byl vytvořen příklad pro jeden z běžnějších scénářů (např. jednoduchý webový server, který spouští vaši hromadu výběru), kde cílem by mohlo být uchování informací v případě vloupání, které by pomohlo sledovat zpět a zjistit, kde penetrace začala. Pokud existuje vhodnější nebo dosažitelný cíl pro použití v např. malý podnik bez významného IT personálu, který by také pomohl.

48
nealmcb

Auditd je mimořádně výkonný monitorovací nástroj. Jak může každý, kdo se na to kdy podíval, potvrdit, primární slabost je použitelnost. Nastavení něčeho, jako je auditd, vyžaduje spoustu důkladných úvah o tom, co přesně co vyžaduje audit konkrétního systému. V otázce jste se rozhodli jako webový server jako náš příkladový systém, což je dobré, protože je to specifické.

Pro argumenty předpokládejme, že existuje formální rozdělení mezi testovací/dev webové servery a produkční webové servery, kde vývojáři webových stránek vykonávají veškerou svou práci na testovacích/dev systémech a změny produkčního prostředí se provádějí v řízeném nasazení.

Díky těmto poměrně velkým předpokladům a soustředění na výrobní systém se můžeme pustit do práce. Když se podíváme na doporučení pro audit v CIS benchmark pro RHEL5 , můžeme začít budovat následující navrhovanou sadu pravidel:

-a exit,always -S unlink -S rmdir
-a exit,always -S stime.*
-a exit,always -S setrlimit.*
-w /etc/group -p wa 
-w /etc/passwd -p wa 
-w /etc/shadow -p wa 
-w /etc/sudoers -p wa
-b 1024
-e 2

To způsobí, že protokoly budou zapisovány vždy, když se ukončí systémové volání rmdir, unlink, stime nebo setrlimit. To by nás mělo informovat, pokud se někdo pokusí smazat soubory nebo jigger s časy. Také jsme nastavili konkrétní soubory na soubory, které definují skupiny, uživatele, hesla a přístup k Sudo. Namísto zkoumání systémových volání u každého z nich bude zapsán protokol auditu pokaždé, když jeden z těchto souborů je buď:

  1. otevřeno v režimech O_WRONLY nebo O_RDWR
  2. atribut se změní

Protože jsme již předpokládali, že mluvíme o produkčním webovém serveru, doporučuji přidat řádek:

-w /var/www -p wa

Tím se budou rekurzivně sledovat všechny soubory pod /var/www strom adresářů.

Nyní můžeme vidět důvod pro předpoklad „kontrolovaného prostředí“, který byl učiněn dříve. Mezi sledováním všech souborů ve webovém kořenovém adresáři, stejně jako všech unlink nebo rmdir událostí, by to mohlo být ve vývojovém prostředí nepřípustně hlučné. Pokud dokážeme předvídat změny souborového systému, například během oken údržby nebo při nasazení událostí, můžeme tento šum přiměřeně odfiltrovat.

Kombinace všeho do jediného, ​​koherentního souboru bychom chtěli /etc/audit/audit.rules vypadat jako

# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 1024

-a exit,always -S unlink -S rmdir
-a exit,always -S stime.*
-a exit,always -S setrlimit.*
-w /var/www -p wa
-w /etc/group -p wa
-w /etc/passwd -p wa
-w /etc/shadow -p wa
-w /etc/sudoers -p wa

# Disable adding any additional rules - note that adding *new* rules will require a reboot
-e 2
41
Scott Pack

Aktualizace: Tento článek je pěkným vysvětlením pravidel auditd a uvádí příklady pro každou událost, kterou byste se mohli přihlásit:

HOWTO_configure_the_auditing_of_the_system_auditd


Podívejte se na hlášení o chybě zde:

https://github.com/gds-operations/puppet-auditd/pull/1

Poskytují velmi dlouhý příklad souboru, který obsahuje mnoho důležitých změn, které by mohly být v systému provedeny. Kopírovat níže pro pohodlí (s malými úpravami):

## Remove any existing rules
-D

## Buffer Size
## Feel free to increase this if the machine panic's
-b 8192

## Failure Mode
## Possible values are 0 (silent), 1 (printk, print a failure message),
## and 2 (panic, halt the system).
-f 1

## Audit the audit logs.
## successful and unsuccessful attempts to read information from the
## audit records; all modifications to the audit trail
-w /var/log/audit/ -k auditlog

## Auditd configuration
## modifications to audit configuration that occur while the audit
## collection functions are operating.
-w /etc/audit/ -p wa -k auditconfig
-w /etc/libaudit.conf -p wa -k auditconfig
-w /etc/audisp/ -p wa -k audispconfig

## Monitor for use of audit management tools
-w /sbin/auditctl -p x -k audittools
-w /sbin/auditd -p x -k audittools

## special files
-a exit,always -F Arch=b32 -S mknod -S mknodat -k specialfiles
-a exit,always -F Arch=b64 -S mknod -S mknodat -k specialfiles

## Mount operations
-a exit,always -F Arch=b32 -S mount -S umount -S umount2 -k mount
-a exit,always -F Arch=b64 -S mount -S umount2 -k mount

## changes to the time
##
-a exit,always -F Arch=b32 -S adjtimex -S settimeofday -S stime -S clock_settime -k time
-a exit,always -F Arch=b64 -S adjtimex -S settimeofday -S clock_settime -k time

## Use stunnel
-w /usr/sbin/stunnel -p x -k stunnel

## cron configuration & scheduled jobs
-w /etc/cron.allow -p wa -k cron
-w /etc/cron.deny -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /etc/cron.daily/ -p wa -k cron
-w /etc/cron.hourly/ -p wa -k cron
-w /etc/cron.monthly/ -p wa -k cron
-w /etc/cron.weekly/ -p wa -k cron
-w /etc/crontab -p wa -k cron
-w /var/spool/cron/crontabs/ -k cron

## user, group, password databases
-w /etc/group -p wa -k etcgroup
-w /etc/passwd -p wa -k etcpasswd
-w /etc/gshadow -k etcgroup
-w /etc/shadow -k etcpasswd
-w /etc/security/opasswd -k opasswd

## monitor usage of passwd
-w /usr/bin/passwd -p x -k passwd_modification

#Monitor for use of tools to change group identifiers
-w /usr/sbin/groupadd -p x -k group_modification
-w /usr/sbin/groupmod -p x -k group_modification
-w /usr/sbin/addgroup -p x -k group_modification
-w /usr/sbin/useradd -p x -k user_modification
-w /usr/sbin/usermod -p x -k user_modification
-w /usr/sbin/adduser -p x -k user_modification

## login configuration and information
-w /etc/login.defs -p wa -k login
-w /etc/securetty -p wa -k login
-w /var/log/faillog -p wa -k login
-w /var/log/lastlog -p wa -k login
-w /var/log/tallylog -p wa -k login

## network configuration
-w /etc/hosts -p wa -k hosts
-w /etc/network/ -p wa -k network

## system startup scripts
-w /etc/inittab -p wa -k init
-w /etc/init.d/ -p wa -k init
-w /etc/init/ -p wa -k init

## library search paths
-w /etc/ld.so.conf -p wa -k libpath

## local time zone
-w /etc/localtime -p wa -k localtime

## kernel parameters
-w /etc/sysctl.conf -p wa -k sysctl

## modprobe configuration
-w /etc/modprobe.conf -p wa -k modprobe

## pam configuration
-w /etc/pam.d/ -p wa -k pam
-w /etc/security/limits.conf -p wa  -k pam
-w /etc/security/pam_env.conf -p wa -k pam
-w /etc/security/namespace.conf -p wa -k pam
-w /etc/security/namespace.init -p wa -k pam

## GDS specific secrets
-w /etc/puppet/ssl -p wa -k puppet_ssl

## postfix configuration
-w /etc/aliases -p wa -k mail
-w /etc/postfix/ -p wa -k mail

## ssh configuration
-w /etc/ssh/sshd_config -k sshd

## changes to hostname
-a exit,always -F Arch=b32 -S sethostname -k hostname
-a exit,always -F Arch=b64 -S sethostname -k hostname

## changes to issue
-w /etc/issue -p wa -k etcissue
-w /etc/issue.net -p wa -k etcissue

## this was to noisy currently.
# log all commands executed by an effective id of 0 aka root.
-a exit,always -F Arch=b64 -F euid=0 -S execve -k rootcmd
-a exit,always -F Arch=b32 -F euid=0 -S execve -k rootcmd

## Capture all failures to access on critical elements
-a exit,always -F Arch=b64 -S open -F dir=/etc -F success=0 -k unauthedfileacess
-a exit,always -F Arch=b64 -S open -F dir=/bin -F success=0 -k unauthedfileacess
-a exit,always -F Arch=b64 -S open -F dir=/sbin -F success=0 -k unauthedfileacess
-a exit,always -F Arch=b64 -S open -F dir=/usr/bin -F success=0 -k unauthedfileacess
-a exit,always -F Arch=b64 -S open -F dir=/usr/sbin -F success=0 -k unauthedfileacess
-a exit,always -F Arch=b64 -S open -F dir=/var -F success=0 -k unauthedfileacess
-a exit,always -F Arch=b64 -S open -F dir=/home -F success=0 -k unauthedfileacess
-a exit,always -F Arch=b64 -S open -F dir=/srv -F success=0 -k unauthedfileacess

## Monitor for use of process ID change (switching accounts) applications
-w /bin/su -p x -k priv_esc
-w /usr/bin/Sudo -p x -k priv_esc
-w /etc/sudoers -p rw -k priv_esc

## Monitor usage of commands to change power state
-w /sbin/shutdown -p x -k power
-w /sbin/poweroff -p x -k power
-w /sbin/reboot -p x -k power
-w /sbin/halt -p x -k power

## Make the configuration immutable
-e 2
14
dberm22

Trochu přistupujete k otázce špatně. Musíte se rozhodnout, co chcete protokolovat, a zjistit, jak se přihlásit. Vytváření spoustu log souborů je v pohodě a všechno, ale pokud se na ně nikdy nedíváte nebo nevíte, co hledáte, ztrácí to čas a prostor.

Při rozhodování o tom, co se přihlásit, musíte zjistit, jaké chování je to, na čem vám záleží, a poté zjistit, jak tuto aktivitu protokolovat. Dobrým způsobem, jak začít s tím, by bylo číst o AppArmor a prozkoumat auditctl manuálovou stránku. poté se naučte, jaká systémová volání jsou dostupná, naučte se programovat pro Unix a identifikujte volání, která by mohla být zajímavá. Je to opravdu velký podnik. Vím, že se jedná o odpověď typu glib a neposkytuje „zde je skript Shell, který bude zaznamenávat vše, na čem vám záleží na vašem serveru“ - ale důvod, proč tyto odpovědi neexistují, je, že každá situace je jiná takže není možné dát odpověď „jedna velikost padne nejvíce“.

Na (sice velkém) místě, kde pracuji, máme celý tým lidí, kteří se věnují pouze systémovému protokolování - nemluvě o různých správních a bezpečnostních týmech, které přispívají. Toto není malé téma. : /

11
dannysauer