సర్వర్‌లో వినియోగదారుల కమాండ్లను ఆడిట్ చేయడం ఎలా?

మీ సర్వర్‌లో వినియోగదారులు రన్ చేసిన కమాండ్లను ఏది రికార్డ్ చేస్తుంది

మీ సర్వర్‌లో వినియోగదారులు ఏ కమాండ్లను రన్ చేశారో ఆడిట్ చేయడానికి, వినియోగదారు ఎడిట్ చేయలేని రికార్డు మీకు అవసరం. Shell history అటువంటి రికార్డు కాదు. ఇది కేవలం సౌకర్యం కోసం ఉండే ఫైల్, దీనిపై ఆ ఖాతాకే యాజమాన్యం ఉంటుంది. ఆ షెల్‌లో టైప్ చేయగల ఎవరైనా దీన్ని ఆపివేయవచ్చు లేదా తొలగించవచ్చు.

నాలుగు పొరలు (layers) నిజమైన రికార్డును ఉంచుతాయి, ప్రతిదానికీ కొంత ఖర్చు ఉంటుంది. sudo ప్రతి కమాండ్‌ను syslog లో ఒక లైన్‌గా రాస్తుంది. sudo I/O logging ఒక ఖాతాకు సంబంధించిన పూర్తి సెషన్‌ను క్యాప్చర్ చేస్తుంది. PROMPT_COMMAND వంటి షెల్ హుక్, ఇంటరాక్టివ్ bash వినియోగదారు ఏమి టైప్ చేశారో లాగ్ చేస్తుంది. కెర్నల్ ఆడిట్ సబ్‌సిస్టమ్ execve syscall ను నేరుగా రికార్డ్ చేస్తుంది, అందుకే ప్రతి ప్రాసెస్‌ను గమనించగలిగే ఏకైక పొర ఇదే. ఈ గైడ్ ఆ క్రమాన్ని వివరిస్తుంది, ప్రతి పొర ఎక్కడ ఆగిపోతుందో చెబుతుంది, మరియు చివరిగా దేనివల్ల ప్రయోజనం ఉందో నిర్ణయించే అంశంతో ముగుస్తుంది: మీరు ఆడిట్ చేస్తున్న వ్యక్తి ఆ రికార్డులను చేరుకోకముందే వాటిని మెషిన్ నుండి బయటకు పంపడం.

మీరు ప్రారంభించే ముందు ఒక హెచ్చరిక. ఆడిట్ సబ్‌సిస్టమ్ అనేది కెర్నల్ పని, కాబట్టి హోస్ట్ కెర్నల్‌ను పంచుకునే కంటైనర్‌లో వీటిని పరీక్షించలేము. ఈ కమాండ్లను మీ స్వంత కెర్నల్ ఉన్న KVM VPS లో రన్ చేయండి.

Shell history ఎందుకు audit trail కాదు

~/.bash_history నాలుగు సాధారణ కారణాల వల్ల సాక్ష్యంగా పనికిరాదు, వీటిలో దేనికీ తెలివైన దాడి చేసే వ్యక్తి అవసరం లేదు.

ఇది వినియోగదారుడికి చెందినది. ఈ ఫైల్ mode 600 లో ఉంటుంది మరియు ఆ ఖాతాకే చెందుతుంది, కాబట్టి rm ~/.bash_history చేయడానికి ఎటువంటి ప్రత్యేక అధికారాలు అవసరం లేదు. అలాగే, ఒక ఎడిటర్‌లో దీన్ని తెరిచి, ముఖ్యమైన ఇరవై లైన్లను తొలగించడం కూడా చాలా సులభం.

షెల్ ముగిసినప్పుడు ఇది వ్రాయబడుతుంది. kill -9 $$ తో ముగిసే సెషన్ లేదా కనెక్షన్ కట్ అయినప్పుడు ఏ సమాచారం వ్రాయబడదు. exit కి ముందు history -c చేసినా అదే జరుగుతుంది, ఏమీ జరగనట్లుగా కనిపిస్తుంది.

ఒక్క పదంతో దీన్ని ఆపివేయవచ్చు. unset HISTFILE ఆ సెషన్ కోసం ఫైల్ వ్రాయబడకుండా ఆపుతుంది. set +o history వెంటనే రికార్డింగ్‌ను నిలిపివేస్తుంది. HISTCONTROL=ignorespace ముందు ఖాళీ స్థలం (leading space) ఉంచి టైప్ చేసిన ప్రతి కమాండ్‌ను దాచిపెడుతుంది. ఇవన్నీ man bash లో భాగంగానే ఉన్నాయి, ఎందుకంటే ఇది వినియోగదారుడి నియంత్రణలో ఉండాలని ఉద్దేశించబడింది.

ఇది ఏమి టైప్ చేశారో రికార్డ్ చేస్తుంది, ఏమి రన్ అయ్యిందో కాదు. ఒక alias లేదా shell function ఉంటే, ఫైల్‌లో ఉన్న టెక్స్ట్ కర్నల్ అమలు చేసిన ప్రోగ్రామ్ కాకపోవచ్చు.

అంతేకాకుండా, ఎంట్రీ వ్రాయబడినప్పుడు HISTTIMEFORMAT సెట్ చేయబడితే తప్ప, ఇందులో timestamps ఉండవు. ఎందుకంటే ఆ variable సెట్ చేసినప్పుడు మాత్రమే bash తన #1755043200 మార్కర్ లైన్లను వ్రాస్తుంది.

ఒక shared login లో, ఇది ఎవరు చేశారో కూడా చెప్పలేదు. ఒకే deploy ఖాతాను ముగ్గురు వ్యక్తులు ఉపయోగిస్తే, ఒకే uid కింద ఒకే ఫైల్‌లో సమాచారం కలిసిపోతుంది. ఇద్దరు వ్యక్తులు ఒకే uid ని పంచుకున్నప్పుడు, ఏ logging layer కూడా ఒక చర్యను నిర్దిష్ట వ్యక్తికి ఆపాదించలేదు. అందుకే shared login కు బదులుగా ప్రతి వ్యక్తికి ఒక unprivileged account ఉండాలని వాదిస్తారు.

Shell history దాని అసలు పనికి మాత్రమే ఉపయోగపడుతుంది, అంటే నిన్న టైప్ చేసిన కమాండ్‌ను మళ్ళీ టైప్ చేయడానికి సహాయపడుతుంది. దీన్ని ఒక సూచనగా మాత్రమే వాడండి. ఎప్పుడూ సాక్ష్యంగా చూపకండి.

sudo ఏమి లాగ్ చేస్తుంది మరియు అది ఎక్కడ ఆగిపోతుంది

sudo తాను రన్ చేసే ప్రతి కమాండ్ కోసం ఒక లైన్‌ను authpriv syslog ఫెసిలిటీకి పంపుతుంది.

sudo grep 'sudo:' /var/log/auth.log | tail -5
journalctl -t sudo -n 5

ప్రతి లైన్ వినియోగదారు పేరు, టెర్మినల్, వర్కింగ్ డైరెక్టరీ, టార్గెట్ వినియోగదారు మరియు కమాండ్‌ను పేర్కొంటుంది:

sudo:    alice : TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/usr/bin/apt update

ఒకవేళ /var/log/auth.log లేకపోతే, ఆ ఇమేజ్‌లో rsyslog ఇన్‌స్టాల్ చేయబడలేదని అర్థం మరియు రికార్డులు కేవలం journal లో మాత్రమే ఉంటాయి. మీరు దానిపై ఆధారపడే ముందు journal వోలటైల్ (volatile) కాదని నిర్ధారించుకోండి:

journalctl --list-boots

కేవలం ప్రస్తుత బూట్ మాత్రమే కనిపిస్తుందంటే /var/log/journal లేదని అర్థం, కాబట్టి journal /run లో ఉంటుంది మరియు ప్రతి లైన్ తదుపరి రీబూట్ వద్ద తొలగించబడుతుంది. దీన్ని పర్సిస్టెంట్ (persistent) చేయండి:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

ఇప్పుడు పరిమితిని గమనించండి. sudo తాను రన్ చేయమని అడిగిన కమాండ్‌ను మాత్రమే లాగ్ చేస్తుంది. ఆ కమాండ్ ఆ తర్వాత ఏమి చేస్తుందో అది లాగ్ చేయదు. కాబట్టి ఒక లైన్‌తోనే ఆ జాడ ముగుస్తుంది:

sudo -i

లాగ్‌లో షెల్ కోసం ఒకే ఒక రికార్డ్ ఉంటుంది. ఆ root షెల్ లోపల టైప్ చేసిన ప్రతి కమాండ్ sudo కి కనిపించదు, ఎందుకంటే sudo ఇకపై ఆ పాత్‌లో ఉండదు. sudo su -, sudo bash, మరియు sudo vim /etc/shadow తర్వాత :!bash అన్నీ ఒకే విధంగా ఉంటాయి. షెల్ ఎస్కేప్ (shell escape) ఉన్న ఏదైనా ప్రోగ్రామ్‌ను అనుమతించే sudoers రూల్, ఉదాహరణకు vim లేదా find, లాగ్ చేయబడని root యాక్సెస్‌ను ఇచ్చే రూల్ అవుతుంది. ఒక అకౌంట్ యొక్క లాగ్ లైన్లను నమ్మే ముందు, ఆ అకౌంట్ వాస్తవానికి దేనిని యాక్సెస్ చేయగలదో చదవండి:

sudo -l -U alice

ఒక ఖాతా కోసం పూర్తి సెషన్‌ను రికార్డ్ చేయడం

ముందుగా మీ వద్ద ఏ sudo వెర్షన్ ఉందో తెలుసుకోండి, ఎందుకంటే Rust రీరైట్‌లో ఈ ఫీచర్ లేదు:

sudo --version | head -1

అవుట్‌పుట్ sudo-rs అని చూపిస్తే, ఈ విభాగాన్ని వదిలేసి audit సబ్‌సిస్టమ్‌ను ఉపయోగించండి. Ubuntu యొక్క 25.10 మరియు 26.04 విడుదలల డాక్యుమెంటేషన్ ప్రకారం I/O లాగింగ్ మరియు sudoreplay సపోర్ట్ చేయబడవు, ఇది ఆగస్టు 2026 నాటికి కూడా నిజం. ఆ విడుదలలలో sudo-rs డిఫాల్ట్‌గా sudo గా ఉంటుంది కాబట్టి, అప్‌గ్రేడ్ చేసినప్పుడు మీరు కలిగి ఉన్న నియంత్రణ తొలగిపోయే అవకాశం ఉంది, అందుకే ఇది ముఖ్యం. ఏదైనా sudo-ఆధారిత లాగింగ్ ప్లాన్ చేసే ముందు sudo-rs ప్రవర్తనలో మార్పుల పూర్తి జాబితా చదవడం మంచిది.

Ubuntu 24.04 LTS లో ఇప్పటికీ అందుబాటులో ఉన్న ఒరిజినల్ sudo తో, ఒక ఖాతా కోసం I/O లాగింగ్‌ను ఇలా ప్రారంభించండి:

sudo visudo -f /etc/sudoers.d/iolog

Defaults:deploy log_output
Defaults!/usr/bin/sudoreplay !log_output

ఎడిటర్‌కు బదులుగా visudo ఉపయోగించండి, ఎందుకంటే ఇది సరిగ్గా పార్స్ కాని ఫైల్‌ను సేవ్ చేయదు. పాడైపోయిన sudoers ఫైల్ అందరినీ sudo నుండి లాక్ చేస్తుంది. ఆ తర్వాత సెషన్‌ను రీప్లే చేయండి:

sudo sudoreplay -l user=deploy
sudo sudoreplay 000001

sudoreplay -l సెషన్లను వాటి IDలతో జాబితా చేస్తుంది, ఒకవేళ ఆ వినియోగదారుకు log_output వర్తించకపోతే ఏమీ చూపదు. దీని వల్ల కలిగే పరిణామాలు: టెర్మినల్ ద్వారా వెళ్ళే ప్రతి బైట్ /var/log/sudo-io కింద నిల్వ చేయబడుతుంది, కాబట్టి ఎక్కువ సమాచారం ఉన్న సెషన్ పరిమాణం పెద్దదిగా ఉంటుంది. రెండవ sudoers లైన్ రీప్లేను మళ్ళీ రికార్డ్ చేయకుండా ఆపుతుంది. దీని అసలు ప్రమాదం రహస్యాల (secrets) విషయంలో ఉంటుంది, ఎందుకంటే I/O లాగ్ సెషన్‌లో టైప్ చేసిన మరియు ప్రింట్ అయిన ప్రతి విషయాన్ని, ప్రాంప్ట్‌లో టైప్ చేసిన పాస్‌వర్డ్‌తో సహా భద్రపరుస్తుంది, కాబట్టి దీనికి పాస్‌వర్డ్ స్టోర్‌కు ఇచ్చేంత భద్రత అవసరం. దీని పరిధి కూడా తక్కువ. ఇది sudo ద్వారా రన్ చేసిన కమాండ్లను మాత్రమే చూస్తుంది. ఎవరైనా లాగిన్ అయ్యి పూర్తిగా తమ సొంత ఖాతాలో పని చేస్తే, అది అస్సలు రికార్డ్ అవ్వదు.

Shell hooks మరియు వాటిని ఎలా దాటవేయవచ్చు

"ప్రతి కమాండ్‌ను లాగ్ చేయండి" అనే పద్ధతి కోసం సాధారణంగా PROMPT_COMMAND హుక్‌ను /etc/profile.d/ లో ఉంచుతారు:

# /etc/profile.d/00-cmdlog.sh
PROMPT_COMMAND='logger -p local6.info -t cmdlog "$(whoami) $$ $(history 1 | sed "s/^ *[0-9]* *//")"'

ప్రతి ప్రాంప్ట్‌ను చూపించే ముందు bash PROMPT_COMMAND ని రన్ చేస్తుంది, కాబట్టి కమాండ్ ముగిసే వరకు ఆగకుండా టైప్ చేసిన వెంటనే అది syslog కు చేరుతుంది. అలాగే logger సిస్టమ్ లాగ్ డెమోన్ ద్వారా రాస్తుంది, కాబట్టి వినియోగదారుని ఫైల్ పర్మిషన్లతో సంబంధం ఉండదు. కొత్త లాగిన్ షెల్‌ను ఓపెన్ చేసి sudo tail -f /var/log/syslog తో లేదా rsyslog లేని ఇమేజ్ అయితే journalctl -t cmdlog -f తో దీన్ని తనిఖీ చేయండి.

అయితే, ఇది ఐదు రకాలుగా పనిచేయడం ఆగిపోతుంది. వీటిని మీరు నిమిషంలోనే పరీక్షించవచ్చు.

• Non-interactive షెల్స్ ఎప్పుడూ ప్రాంప్ట్‌ను చూపవు. ssh you@server 'id' కమాండ్‌ను రన్ చేసి వెనక్కి వస్తుంది, కానీ ఏదీ లాగ్ అవ్వదు, ఎందుకంటే PROMPT_COMMAND ఎప్పుడూ అమలు కాదు.
• ఇది ఒక వేరియబుల్. unset PROMPT_COMMAND సెషన్ ముగిసే వరకు దీన్ని డిసేబుల్ చేస్తుంది, దీనికి ఎటువంటి ప్రివిలేజెస్ అవసరం లేదు.
• ఈ ఫైల్ లాగిన్ షెల్స్ ద్వారా మాత్రమే చదవబడుతుంది. bash --noprofile --norc ఎప్పుడూ /etc/profile.d/ ని సోర్స్ చేయదు.
• ఇది కేవలం bash కి మాత్రమే పరిమితం. vim లోపల ఉండే zsh, sh, python3 -c 'import os; os.system("id")' మరియు :!id అన్నీ వేరే ప్రోగ్రామ్‌లను రన్ చేస్తాయి, వీటిని ఏ bash ప్రాంప్ట్ హుక్ గుర్తించలేదు.
• ఇది టైప్ చేసినట్లుగానే లాగ్ చేస్తుంది, కాబట్టి alias లేదా function ద్వారా రన్ చేసిన అసలు కమాండ్ బయటపడదు.

Shell hook ను కేవలం సౌలభ్యం కోసం మాత్రమే వాడండి. సహకరించే వినియోగదారుల విషయంలో "గత మంగళవారం నేను ఏమి రన్ చేశాను" అనే ప్రశ్నకు ఇది సమాధానం ఇస్తుంది. దీన్ని ఒక సెక్యూరిటీ కంట్రోల్‌గా పరిగణించవద్దు.

కెర్నల్ ఆడిట్ సబ్‌సిస్టమ్ ప్రతి execve ను గమనిస్తుంది

Linux ఆడిట్ సబ్‌సిస్టమ్, ఇది auditd డెమోన్ ద్వారా నడుస్తుంది, ఇది వినియోగదారుడు తప్పించుకోలేని ఏకైక పొర. ఎందుకంటే syscall రన్ అవుతున్న క్షణంలోనే కెర్నల్ లోపల రికార్డు సృష్టించబడుతుంది. ఒక ప్రాసెస్ ప్రోగ్రామ్‌ను ఎగ్జిక్యూట్ చేస్తే, ఒక ఈవెంట్ నమోదవుతుంది. షెల్, ప్రోగ్రామింగ్ లాంగ్వేజ్ లేదా టెర్మినల్ ఉనికితో సంబంధం లేకుండా ఇది జరుగుతుంది.

sudo apt update && sudo apt install -y auditd audispd-plugins
sudo systemctl enable --now auditd
sudo auditctl -s

auditctl -s డెమోన్ స్థితిని ప్రింట్ చేస్తుంది. pid సున్నా కాని విలువతో ఉన్న enabled 1 అంటే అది రన్ అవుతోందని అర్థం, మరియు lost 0 అంటే ఇప్పటివరకు ఎటువంటి రికార్డులు డ్రాప్ కాలేదని అర్థం. ఆ lost కౌంటర్‌ను గుర్తుంచుకోండి, అది తర్వాత మళ్ళీ వస్తుంది.

auid అనేది ఆడిట్‌ను విలువైనదిగా చేసే ఫీల్డ్. ఒక సెషన్ ప్రారంభమైనప్పుడు PAM ఒక login uid ని సెట్ చేస్తుంది, ఆ తర్వాత కెర్నల్ ప్రతి చైల్డ్ ప్రాసెస్‌కు దానిని మోసుకెళ్తుంది. మీ దానిని ఇలా తనిఖీ చేయండి:

cat /proc/self/loginuid

ఒక ఇంటరాక్టివ్ SSH సెషన్ మీ uid ని ప్రింట్ చేస్తుంది, ఎందుకంటే /etc/pam.d/sshd లో pam_loginuid.so ఉంటుంది. 4294967295 విలువ అంటే loginuid ఎప్పుడూ సెట్ చేయబడలేదని అర్థం, ఇది బూట్ సమయంలో సిస్టమ్ డెమోన్ ద్వారా ప్రారంభించబడిన ప్రాసెస్‌లకు సాధారణం. ముఖ్యమైన విషయం ఏమిటంటే sudo -i దానిని మార్చదు: alice ద్వారా తెరవబడిన root షెల్ ఇప్పటికీ auid 1000 నే కలిగి ఉంటుంది, కాబట్టి అందులోని ప్రతి కమాండ్ alice కు ఆపాదించబడుతుంది. sudo వదిలివేసే లోపం సరిగ్గా ఇదే. ఒకసారి సెట్ చేసిన loginuid ని మార్చడానికి CAP_AUDIT_CONTROL అవసరం, ఇది సాధారణ వినియోగదారులకు ఉండదు, మరియు sudo auditctl --loginuid-immutable తదుపరి రీబూట్ వరకు root కోసం కూడా దానిని మూసివేస్తుంది.

/etc/pam.d/sshd, /etc/pam.d/login మరియు /etc/pam.d/cron ప్రతి ఒక్కటి pam_loginuid.so ని కలిగి ఉన్నాయని నిర్ధారించుకోండి, లేకపోతే ఈవెంట్‌లు ఎవరికీ అనుసంధానించబడకుండా వస్తాయి. మీరు VPS పై SSH యాక్సెస్‌ను హార్డెనింగ్ చేయడం చేసేటప్పుడు తాకే ఫైల్ జాబితా ఇదే, కాబట్టి ఈ రెండు పనులను కలిపి చేయండి.

auditd కోసం ప్రారంభ నియమాల సమితి

నియమాలు /etc/audit/rules.d/*.rules లో ఉంటాయి. augenrules వాటిని ఫైల్ పేరు క్రమంలో ఒకే జాబితాగా కలుపుతుంది. కెర్నల్ మొదటి సరిపోలిన నియమం వద్ద ఆగిపోతుంది కాబట్టి, నియమాల క్రమం ప్రవర్తనను నిర్ణయిస్తుంది. మీరు ఏదైనా జోడించే ముందు ఇప్పటికే అక్కడ ఉన్న వాటిని చదవండి, ఎందుకంటే తర్వాత వచ్చే ఫైల్‌లోని -D అంతకుముందు లోడ్ అయిన వాటన్నింటినీ తొలగిస్తుంది.

ls /etc/audit/rules.d/
cat /etc/audit/rules.d/audit.rules

ఆ తర్వాత /etc/audit/rules.d/50-exec.rules రాయండి:

## Suppressions first: the kernel takes the first matching rule.
-a never,exit -F arch=b64 -S execve -F exe=/usr/bin/dpkg
-a never,exit -F arch=b64 -S execve -F exe=/usr/bin/dpkg-deb
-a never,exit -F arch=b64 -S execve -F exe=/usr/bin/dpkg-query
-a never,exit -F arch=b64 -S execve -F exe=/usr/bin/dpkg-split
-a never,exit -F arch=b64 -S execve -F exe=/usr/bin/dpkg-trigger

## Every program started by a logged-in human.
-a always,exit -F arch=b64 -S execve,execveat -F auid>=1000 -F auid!=unset -k exec
-a always,exit -F arch=b32 -S execve,execveat -F auid>=1000 -F auid!=unset -k exec

## Changes to who may become root.
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity

## Changes to the audit configuration itself.
-w /etc/audit/ -p wa -k auditconfig

దీనిని లోడ్ చేసి నిర్ధారించండి:

sudo augenrules --load
sudo auditctl -l

auditctl -l మీ నియమాలను తిరిగి ప్రింట్ చేస్తుందంటే అవి అమలులో ఉన్నాయని అర్థం. No rules అంటే లోడ్ విఫలమైందని అర్థం, మరియు journalctl -u auditd -n 20 పార్సర్ తిరస్కరించిన ఫైల్ పేరును మరియు లైన్ నంబర్‌ను తెలియజేస్తుంది. పాత audit userspace వెర్షన్లకు unset కీవర్డ్ అర్థం కాదు. లోడర్ ఆ ఫీల్డ్ గురించి ఫిర్యాదు చేస్తే, దానికి బదులుగా -F auid!=4294967295 అని రాయండి, ఇది అదే విలువను సూచిస్తుంది.

ఇప్పుడు ఈవెంట్లను తిరిగి చదవండి:

sudo ausearch -k exec -ts recent -i | tail -40
sudo ausearch -ul 1000 -ts today -i
sudo aureport -k --summary -i

-i అనేది uidలను మరియు syscall నంబర్లను పేర్లుగా మారుస్తుంది, ఆచరణలో ఇది తప్పనిసరి. -ts recent గత పది నిమిషాల సమయాన్ని కవర్ చేస్తుంది. ప్రతి ఎగ్జిక్యూషన్ రికార్డుల సమూహంగా వస్తుంది: uid, auid, exit status మరియు keyని కలిగి ఉన్న SYSCALL రికార్డు, పూర్తి ఆర్గ్యుమెంట్ జాబితాతో ఉన్న EXECVE రికార్డు, మరియు సందర్భం కోసం CWD మరియు PATH రికార్డులు ఉంటాయి.

ఒక ముఖ్యమైన పరిమితిని గమనించాలి, ఎందుకంటే ఇది చాలామందిని అయోమయానికి గురి చేస్తుంది. audit అనేది syscallలను రికార్డ్ చేస్తుంది, కానీ shell builtin కమాండ్ దేనికీ సొంతంగా syscall ఉండదు. cd /root ఏ ప్రోగ్రామ్‌ను రన్ చేయదు. bash ప్రాంప్ట్ వద్ద టైప్ చేసిన echo evil >> /etc/passwd కూడా ఏ ప్రోగ్రామ్‌ను రన్ చేయదు, ఎందుకంటే echo మరియు redirect రెండూ ఇప్పటికే రన్ అవుతున్న shell ప్రాసెస్‌లోనే జరుగుతాయి. కాబట్టి execve నియమాలు ప్రోగ్రామ్‌లను చూస్తాయి మరియు -w నియమాలు రైట్‌లను (writes) చూస్తాయి. ఏ ఒక్కటీ మాత్రమే సరిపోదు.

చివరగా, కాన్ఫిగరేషన్‌ను లాక్ చేయండి:

## /etc/audit/rules.d/99-finalize.rules
-e 2

-e 2 అనేది తదుపరి రీబూట్ వరకు నియమాల సమితిని మార్చలేనిదిగా (immutable) చేస్తుంది. ఇది లోడ్ అయిన తర్వాత, auditctl -s అనేది enabled 2 అని రిపోర్ట్ చేస్తుంది, మరియు రూట్ యూజర్‌తో సహా ఎవరైనా నియమాన్ని జోడించడానికి లేదా తొలగించడానికి ప్రయత్నిస్తే అది Operation not permitted తో విఫలమవుతుంది. ఈ ఫైల్‌ను చివరగా జోడించండి, మరియు మీరు నియమాన్ని మార్చాలనుకున్న ప్రతిసారీ రీబూట్ చేయాల్సి ఉంటుందని గుర్తుంచుకోండి. ఈ మార్పులే దీని ఉద్దేశ్యం: ఎవరైనా సులభంగా ఆపివేయగలిగే నియమాల సమితి సాక్ష్యంగా పనికిరాదు.

ఎవరూ చదవని ఆడిట్ లాగ్ కేవలం ఒక కంప్లయన్స్ డాక్యుమెంట్ మాత్రమే

auditd విఫలమవ్వడానికి కారణం అది సమాచారాన్ని మిస్ అవ్వడం కాదు. అది ఎంత ఎక్కువ సమాచారాన్ని రికార్డ్ చేస్తుందంటే, ఎవరూ దాన్ని పరిశీలించరు. ఫలితంగా, ఆ లాగ్ ఏదైనా ప్రశ్నకు సమాధానం ఇవ్వడానికి కాకుండా, కేవలం చెక్‌లిస్ట్ పూర్తి చేయడానికి మాత్రమే ఉపయోగపడుతుంది.

ఏదైనా ట్యూన్ చేసే ముందు మీ సర్వర్‌లో ఈ గణనను ఒకసారి చూసుకోండి:

sudo aureport -k --summary -i
sudo du -sh /var/log/audit

ఒక సింగిల్ sudo apt upgrade వేలకొద్దీ స్వల్పకాలిక ప్రాసెస్‌లను రన్ చేస్తుంది. ప్రతి ప్రాసెస్ మీ auid ని కలిగి ఉంటుంది, కాబట్టి ఒక ప్యాకేజీ అప్‌డేట్ అనేది ఒక వారం రోజుల మానవ టైపింగ్‌ కంటే ఎక్కువ డేటాను సృష్టిస్తుంది. అందుకే పైన పేర్కొన్న సప్రెషన్లు dpkg మరియు దాని సహాయక ప్రోగ్రామ్‌లను పేర్కొన్నాయి. ఎప్పుడూ ఎగ్జిక్యూటబుల్ ఫైల్ ఆధారంగానే మినహాయింపులు ఇవ్వండి, యూజర్ ఆధారంగా వద్దు: /usr/bin/dpkg కోసం ఇచ్చే మినహాయింపును ఒక వాక్యంలో వివరించవచ్చు, కానీ ఒక అకౌంట్ కోసం ఇచ్చే మినహాయింపు మీరు దేనినైతే పట్టుకోవాలని చూస్తున్నారో అదే ఆకారంలో ఉన్న ఒక భద్రతా లోపం అవుతుంది.

ప్రతి రూల్‌పై ఉండే -k కీ, ఒక నెల తర్వాత కూడా లాగ్‌ను వెతకడానికి వీలు కల్పిస్తుంది. ausearch -k sudoers అనేది ఒక ప్రశ్నకు సమాధానం లాంటిది. ఫిల్టర్ లేని ausearch అనేది కేవలం టెక్స్ట్ గోడలా ఉంటుంది, ఇది మిమ్మల్ని లాగ్ చదవడం మానేసేలా చేస్తుంది. మీ కలెక్టర్ నేటివ్ ఫార్మాట్‌కు బదులుగా JSON కోరుకుంటే, laurel అనే auditd ప్లగిన్‌ను వాడండి. ఇది ప్రతి ఈవెంట్‌ను డీకోడ్ చేసిన ఆర్గ్యుమెంట్లతో కూడిన ఒక JSON ఆబ్జెక్ట్‌గా మారుస్తుంది. ఇది ఇతర ప్లగిన్‌ల మాదిరిగానే /etc/audit/plugins.d/ లో రిజిస్టర్ అవుతుంది, మరియు auditd ప్లగిన్ మార్పులను sudo pkill -HUP auditd వద్ద గుర్తిస్తుంది.

auditd వల్ల కలిగే ఖర్చులు, నిజాయితీగా చెప్పాలంటే

ప్రతి matching syscall ఒక record గా మారుతుంది. kernel దీనిని format చేసి userspace కు పంపుతుంది. దీని వల్ల కలిగే భారం రెండు చోట్ల ఉంటుంది. ఇతరులు చెప్పే అంచనాల కంటే, మీ స్వంత workload పైనే దీనిని ఖచ్చితంగా కొలవవచ్చు.

• CPU మరియు latency. నిరంతరం fork అయ్యే machine, అంటే build host లేదా CI runner, ప్రతి exec కు ఒక record ను ఉత్పత్తి చేస్తుంది. kernel backlog నిండినప్పుడు, --backlog_wait_time ఆ event ను సృష్టించిన process ను ఖాళీ అయ్యే వరకు నిలిపివేస్తుంది. కాబట్టి, audit అనేది CPU percentage గా కాకుండా, slow builds రూపంలో కనిపిస్తుంది. నిజమైన load ఉన్నప్పుడు sudo auditctl -s లో backlog మరియు lost లను గమనించండి. lost పెరుగుతుందంటే records drop అవుతున్నాయని అర్థం. log లో ఖాళీలు ఉండటం అసలు log లేకపోవడం కంటే ప్రమాదకరం, ఎందుకంటే మీరు దానిని నమ్ముతారు కాబట్టి.
• Disk. /etc/audit/auditd.conf చదవండి మరియు disk నిండినప్పుడు ఏమి జరగాలి అనేది నిర్ణయించుకోండి, ఎందుకంటే default విలువలు కేవలం అభిప్రాయాలు మాత్రమే. max_log_file, num_logs మరియు max_log_file_action rotation ను నియంత్రిస్తాయి. space_left_action, admin_space_left_action మరియు disk_full_action అత్యవసర పరిస్థితులను నియంత్రిస్తాయి. అందుబాటులో ఉన్న కొన్ని చర్యలు, ముఖ్యంగా halt మరియు single, record కోల్పోవడం కంటే machine నే ఆపివేస్తాయి.

/etc/audit/rules.d/audit.rules లోని -f లైన్ kernel స్థాయిలో ఇదే నిర్ణయాన్ని తీసుకుంటుంది: -f 1 audit failure ను syslog కు పంపుతుంది, మరియు -f 2 kernel ను panic చేస్తుంది. ఒకవేళ record కోల్పోవడం కంటే server ఆగిపోవడమే మేలు అనుకుంటేనే 2 ను ఎంచుకోండి. ప్రజలు ఆధారపడే VPS లో, rotation ను ఎంచుకుని, storage సమస్యను ఆ box బయటకు తరలించడం మంచిది.

Logs ను సర్వర్ నుంచి బయటకు, దాదాపు real-time లో పంపడం

ఇన్సిడెంట్ రిపోర్టులు పదేపదే నిరూపిస్తున్న విషయం ఇదే. compromised అయిన host పైనే logs ఉంటే, ఆ సర్వర్‌ను హ్యాక్ చేసిన వారు వాటిని మార్చగలరు. root యూజర్ /var/log/auth.log ను తిరిగి రాయగలరు, /var/log/audit/audit.log ను తొలగించగలరు మరియు daemon ను ఆపివేయగలరు. -e 2 నియమాలను తొలగించకుండా ఆపుతుంది, కానీ rm విషయంలో ఇది ఏమీ చేయలేదు. పైన పేర్కొన్న ప్రతి అంచె (layer) కేవలం ఒక కాపీ సర్వర్ నుంచి బయటకు వెళ్ళినప్పుడే సాక్ష్యాలను భద్రపరచగలదు.

Audit యొక్క సొంత రవాణా వ్యవస్థ audispd-plugins లోని audisp-remote ప్లగిన్. దీన్ని /etc/audit/plugins.d/au-remote.conf లో ఆన్ చేయండి:

active = yes
direction = out
path = /usr/sbin/audisp-remote
type = always
format = string

మీరు reload చేసే ముందు command -v audisp-remote తో path ను సరిచూసుకోండి, ఎందుకంటే తప్పుడు path ఇస్తే journal లో ఒక లైన్ తప్ప మరేమీ రాదు. /etc/audit/audisp-remote.conf లో remote_server మరియు port లను సెట్ చేయండి, అలాగే collector వైపు దాని సొంత auditd.conf లో tcp_listen_port = 60 ను సెట్ చేయండి. sudo pkill -HUP auditd తో reload చేయండి. చాలా images లో systemctl restart auditd తిరస్కరించబడుతుంది, ఎందుకంటే unit file లో RefuseManualStop=yes సెట్ చేయబడి ఉంటుంది, కాబట్టి signal పంపడమే నమ్మదగిన మార్గం.

మరో ఎంపిక ఏమిటంటే, audit ను మీరు ఇప్పటికే forward చేస్తున్న syslog stream లోకి పంపడం. active = no తో /etc/audit/plugins.d/syslog.conf వస్తుంది. దీన్ని yes కు సెట్ చేసి, reload చేయండి; అప్పుడు audit events అన్నీ sudo లైన్లు మరియు ఇతర వాటితో కలిసిపోతాయి. ఆ తర్వాత rsyslog ద్వారా TLS (transport layer security) ఉపయోగించి వాటన్నింటినీ forward చేయండి, దీనికి rsyslog-gnutls ప్యాకేజీ అవసరం:

# /etc/rsyslog.d/60-forward.conf
*.* action(type="omfwd"
    target="logs.example.net" port="6514" protocol="tcp"
    StreamDriver="gtls" StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
    StreamDriverPermittedPeers="logs.example.net"
    action.resumeRetryCount="-1"
    queue.type="linkedList" queue.filename="fwd" queue.saveOnShutdown="on")

Queue సెట్టింగులు చాలా ముఖ్యమైనవి. action.resumeRetryCount="-1" ఎల్లప్పుడూ ప్రయత్నిస్తూనే ఉంటుంది, మరియు queue.saveOnShutdown="on" తో కూడిన disk-assisted queue, collector అందుబాటులో లేనప్పుడు రికార్డులను భద్రపరుస్తుంది, అది తిరిగి రాగానే వాటిని పంపుతుంది. ఈ రెండు లేకపోతే, collector reboot అయినప్పుడు మీ సాక్ష్యాలలో ఖాళీ ఏర్పడుతుంది మరియు ఆ ఖాళీ గురించి మీకు ఎటువంటి సమాచారం అందదు. sudo systemctl restart rsyslog తో వీటిని అమలు చేయండి, ఆపై మీరు దేనినైనా నమ్మే ముందు రికార్డులు collector కు చేరుతున్నాయని నిర్ధారించుకోండి.

చివరగా ఒక విషయం: collector అనేది audit చేయబడే వ్యక్తులు లాగిన్ అవ్వలేని సర్వర్ అయి ఉండాలి. ఒకవేళ log సర్వర్‌పై కూడా అదే admin గ్రూపుకు root యాక్సెస్ ఉంటే, మీరు ఫైల్‌ను కాపీ చేశారు కానీ దాన్ని రక్షించలేదు. వేర్వేరు credentials, వేర్వేరు keys, మరియు వీలైతే వేర్వేరు provider ఖాతాలను వాడండి. అనేక Linux సర్వర్లను నిర్వహించడానికి ఒక కేంద్ర మార్గం అవసరానికి ముందే నిర్మించుకోవడం వెనుక ఉన్న తర్కం ఇదే. compromised అయిన VPS తో పనిచేస్తున్నప్పుడు మొదటి గంటలో మీ పని ఉపయోగకరంగా ఉంటుందా లేదా అనేది దీనిపైనే ఆధారపడి ఉంటుంది.

సాధారణ వినియోగదారు రికార్డును తిరిగి రాయలేరని నిర్ధారించుకోండి

ఊహించుకునే బదులు, వాదనను పరీక్షించండి. sudo లేని సాధారణ ఖాతా నుండి ఇలా చేయండి:

echo test >> /var/log/auth.log
cat /var/log/audit/audit.log
auditctl -D
id -nG

క్రమ పద్ధతిలో వీటిని ఆశించండి: Permission denied, ఎందుకంటే auth.log అనేది syslog యాజమాన్యంలో, adm గ్రూపుతో మరియు 640 మోడ్‌లో ఉంది; మళ్ళీ Permission denied, ఎందుకంటే ఆడిట్ లాగ్ 600 మోడ్‌లో ఉండి root యాజమాన్యంలో ఉంటుంది; రన్ చేయడానికి నిరాకరించే ఎర్రర్, ఎందుకంటే ఆడిట్ నియమాలను మార్చడానికి CAP_AUDIT_CONTROL అవసరం; మరియు adm లేదా systemd-journal లేని గ్రూప్ జాబితా.

చివరి పరీక్షలో చాలామంది విఫలమవుతుంటారు. adm లో సభ్యత్వం ఉంటే /var/log/auth.log కి రీడ్ యాక్సెస్ లభిస్తుంది, మరియు systemd-journal లో సభ్యత్వం ఉంటే మొత్తం జర్నల్‌కు రీడ్ యాక్సెస్ లభిస్తుంది. ఈ రెండింటిలో దేనికీ రైట్ యాక్సెస్ ఉండదు, కాబట్టి ఏదీ డేటాను మార్చడానికి అనుమతించదు. ఈ రెండూ ఒక వ్యక్తిని సర్వర్‌లోని ప్రతి అథెంటికేషన్ లైన్‌ను చదవడానికి అనుమతిస్తాయి, కాబట్టి ఫోరమ్ సమాధానం నుండి ఏదో ఒక usermod -aG లైన్‌ను కాపీ చేసే బదులు, దీనిని ఉద్దేశపూర్వకంగా నిర్ణయించుకోవాలి.

చివరగా, రీబూట్ తర్వాత కూడా ఉండాల్సిన రెండు అంశాలను నిర్ధారించుకోండి:

sudo auditctl -s
systemctl is-enabled auditd

enabled 2 అంటే తదుపరి బూట్ వరకు నియమాల సెట్ లాక్ చేయబడిందని అర్థం. రెండవ కమాండ్ నుండి వచ్చే enabled అంటే ఆ బూట్ తర్వాత auditd మళ్ళీ ప్రారంభమవుతుందని అర్థం. తదుపరి కెర్నల్ అప్‌డేట్ వరకు మాత్రమే ఉండే నియమాల సెట్ ఆడిట్ ట్రైల్ అనిపించుకోదు.

FAQ

ఒక నిర్దిష్ట వినియోగదారు రన్ చేసిన ప్రతి కమాండ్‌ను నేను ఎలా చూడగలను?

id -u alice ఉపయోగించి వారి uidని కనుగొనండి, ఆపై audit logలో login uid ద్వారా వెతకండి: sudo ausearch -ul 1000 -ts today -i. execve నియమానికి పరిమితం చేయడానికి -k execని జోడించండి. login uid అనేది లాగిన్ సమయంలోనే సెట్ చేయబడుతుంది మరియు ఇది su, sudo -i తర్వాత కూడా అలాగే ఉంటుంది, కాబట్టి ఆ ఖాతా ద్వారా తెరిచిన root shell లోపల రన్ చేసిన కమాండ్‌లను కూడా ఇది పట్టుకుంటుంది. నియమాలు లోడ్ అయిన తర్వాత అమలు చేసిన కమాండ్‌లకు మాత్రమే ఇది పనిచేస్తుంది, ఎందుకంటే రికార్డ్ చేయమని కాన్ఫిగర్ చేయని ఈవెంట్‌ల చరిత్రను audit ఉంచదు. మీరు డేటా యొక్క స్వభావాన్ని ముందుగా చూడాలనుకుంటే, sudo aureport -k --summary -i ప్రతి నియమం యొక్క గణాంకాలను చూపుతుంది.

ఒక వినియోగదారు తాము రన్ చేసిన వాటిని దాచడానికి తమ bash historyని తొలగించగలరా?

అవును, దీనికి ఎటువంటి ప్రత్యేక అధికారాలు అవసరం లేదు. ~/.bash_history ఆ వినియోగదారు యాజమాన్యంలో ఉండి 600 మోడ్‌లో ఉంటుంది, కాబట్టి వారు దానిని ఎడిట్ చేయవచ్చు, కత్తిరించవచ్చు (truncate) లేదా తొలగించవచ్చు. వారు unset HISTFILE తో ఫైల్‌లో రాయడం ఆపవచ్చు, set +o history తో సెషన్ మధ్యలో రికార్డింగ్‌ను నిలిపివేయవచ్చు, లేదా HISTCONTROL=ignorespace సెట్ చేసినప్పుడు కమాండ్ ముందు ఖాళీని (space) ఉంచి టైప్ చేయడం ద్వారా ఆ కమాండ్‌ను దాచవచ్చు. షెల్ నిష్క్రమించినప్పుడు bash ఫైల్‌ను రాస్తుంది, కాబట్టి kill -9 $$ తో కిల్ చేసిన సెషన్ ఏదీ రికార్డ్ అవ్వదు. షెల్ హిస్టరీని కేవలం ఒక సూచనగా మాత్రమే చూడండి, ఆధారంగా కాదు.

sudo అనేది sudo -i లోపల ఏమి జరుగుతుందో లాగ్ చేస్తుందా?

లేదు. sudo తాను రన్ చేయాల్సిన కమాండ్‌ను మాత్రమే లాగ్ చేస్తుంది, కాబట్టి sudo -i షెల్ కోసం ఒక లైన్‌ను మాత్రమే ఉత్పత్తి చేస్తుంది, ఆ తర్వాత ఏమీ ఉండదు. ఆ root shell లో టైప్ చేసిన ప్రతి కమాండ్ sudoకు కనిపించదు, ఎందుకంటే sudo ఇకపై ఆ ప్రక్రియలో ఉండదు. sudo su -, sudo bash మరియు షెల్ ఎస్కేప్ అనుమతించే ఏదైనా ప్రోగ్రామ్ ఇలాగే ప్రవర్తిస్తాయి. ఈ లోపాన్ని సరిచేయడానికి రెండు మార్గాలు ఉన్నాయి: execve పై audit నియమాలను ఉంచడం, ఇది అసలు login uidతో ప్రతి ప్రోగ్రామ్‌ను రికార్డ్ చేస్తుంది, మరియు షెల్ యాక్సెస్ ఇవ్వని sudoers నియమాలను అమలు చేయడం.

auditd నా సర్వర్ వేగాన్ని తగ్గిస్తుందా?

ఇది పూర్తిగా మీ వర్క్‌లోడ్ ఎన్ని ప్రాసెస్‌లను ప్రారంభిస్తుంది అనే దానిపై ఆధారపడి ఉంటుంది, కాబట్టి ఒక అంచనాను నమ్మే బదులు స్వయంగా పరీక్షించండి. ఎక్కువగా అభ్యర్థనలకు సమాధానమిచ్చే సర్వర్ తక్కువగా exec చేస్తుంది, కాబట్టి అక్కడ ఎటువంటి ప్రభావం ఉండదు. బిల్డ్ హోస్ట్ లేదా CI రన్నర్ నిరంతరం exec చేస్తాయి కాబట్టి అక్కడ ప్రభావం కనిపించవచ్చు, ఎందుకంటే kernel audit బ్యాక్‌లాగ్ నిండినప్పుడు, ఈవెంట్‌ను సృష్టించిన ప్రాసెస్ ఖాళీ అయ్యే వరకు నిలిపివేయబడుతుంది. వాస్తవ లోడ్ కింద sudo auditctl -s రన్ చేసి backlog మరియు lost లను గమనించండి. lost సున్నా కంటే ఎక్కువగా ఉంటే రికార్డులు డ్రాప్ అయ్యాయని అర్థం, ఇది చాలా చెత్త ఫలితం, ఎందుకంటే లాగ్‌లో ఇప్పుడు కనిపించని ఖాళీలు ఏర్పడతాయి.

audit లాగ్‌లను ఎక్కడ నిల్వ చేయాలి?

వేరొక మెషీన్‌లో, కొన్ని సెకన్ల ఆలస్యంతో నిల్వ చేయాలి. ఆడిట్ చేయబడిన హోస్ట్‌లో root యాక్సెస్ ఉన్న ఎవరైనా /var/log/audit/audit.logని తొలగించి /var/log/auth.logని తిరిగి రాయగలరు, కాబట్టి స్థానిక కాపీలు ఎవరూ దాచడానికి ప్రయత్నించని సంఘటనల గురించి మాత్రమే సమాధానాలు ఇస్తాయి. audisp-remote ప్లగిన్‌తో సెంట్రల్ auditdకి ఫార్వర్డ్ చేయండి, లేదా audit syslog ప్లగిన్‌ను ఎనేబుల్ చేసి rsyslog ద్వారా TLS మీద మొత్తం syslog స్ట్రీమ్‌ను ఫార్వర్డ్ చేయండి. కలెక్టర్‌కు దాని స్వంత క్రెడెన్షియల్స్ ఇవ్వండి, మరియు ఆడిట్ చేయబడుతున్న ఖాతాలకు దానికి యాక్సెస్ లేదని నిర్ధారించుకోండి.