前阵子有个老同事打电话问我说现在想从运维转安全该从哪捡起来。我愣了一下想起自己十年前从运维岗离开兜兜转转又回了网络安全这条线确实有不少话可以说。这个系列写到第四篇前面聊了网络基础、渗透思路、防御体系的搭建这篇专门说说Linux系统——不管你是刚入行做安全运维还是搞渗透测试、应急响应Linux都是绕不开的底盘。十年前我做运维的时候天天跟CentOS 6、iptables、LNMP环境打交道那时候觉得Linux就是个跑服务的操作系统稳定、抗造、能扛并发就行。现在重新回到安全行业再看Linux视角完全不一样了同样是看一个系统以前关心的是服务怎么跑起来、资源够不够用现在关心的是这个系统有没有被入侵过、哪些地方可以被利用、日志里藏着什么线索。这篇就把我重新捡起Linux之后的一些实操经验整理出来包括安全视角下的基础巩固、常用排查命令、加固实操、日志分析还有一些踩过的坑。内容不会太基础但也不会一上来就甩内核源码适合有一定Linux操作经验、刚转安全方向或者做安全运维想系统梳理一遍的朋友。1. 安全视角下的Linux和运维视角有什么不一样先说我自己的体会。当年做运维Linux在我眼里是这样一个东西装好系统配好IP部署Nginx、MySQL、PHP然后写监控脚本盯着负载和磁盘出问题就上去重启服务或者调参数。那时候最怕的是半夜磁盘满了或者某个进程把CPU吃满业务告警。重新回到安全行业再看同一台Linux服务器问题就变成了另外一副面孔开放的端口是不是必要的系统里有没有可疑的账号某个二进制文件是不是被人动过手脚日志里那些登录失败的IP是不是在暴力破解一个文件的时间戳为什么和它周围的文件对不上这两种视角的差异本质上是从“让系统干活”变成了“审视系统的一切行为”。十年前我可能一个月都看不了一次last命令的输出现在几乎是排查问题的第一站。1.1 先放下运维时候的惯性思维运维出身的人有个特点遇到系统异常第一反应是“服务挂了赶紧拉起来”。但安全视角要求你多问一句服务是怎么挂的是不是被人搞挂的如果是被人搞挂的是怎么进来的进来之后干了什么现在还在不在这不是矫情而是实际教训。我之前处理过一个模拟项目X的应急事件某台测试服务器上的Web服务莫名其妙重启了运维同事直接systemctl restart完事。结果第二天又挂了排查才发现是被人上传了定时任务每隔几分钟就拉一次恶意脚本。如果第一次异常时就查一下crontab -l和最近的文件变更根本不用折腾两天。所以做安全第一步就是改掉“重启解决问题”的毛病。系统异常先别急着操作先保留现场、收集信息再决定怎么处理。这不是说运维习惯不好而是目标不同运维要的是恢复业务安全要的是搞清楚发生了什么。1.2 熟悉发行版差异但别被差异带偏国内服务器用CentOS/Rocky/Alma这系的多也有不少Ubuntu/Debian。做安全你需要熟悉它们的差异但不至于被差异困住。举几个实际会遇到的差异包管理yum/dnf对应apt装软件、查已装软件包的命令不同。服务管理现在基本都是systemd但有些老系统还是init脚本service和systemctl都要会。用户与组useradd的参数略有差异Ubuntu默认会创建home目录CentOS需要加-m。防火墙CentOS/Rocky默认是firewalldUbuntu默认是ufw底层都是iptables/nftables但命令差异很大。文件路径/etc/sysconfig/network-scripts/是RHEL系的网络配置Debian系是/etc/network/interfaces当然现在NetworkManager用得更多了。我建议在安全排查的时候先问一句“这是什么发行版”再动手。之前见过有人拿着CentOS的思维去改Ubuntu的网络配置折腾半天没生效其实人家用的是netplan配置文件在/etc/netplan/下。这种问题不涉及多高深的技术纯粹是对系统不够熟。但另一方面很多核心的东西是跨发行版一致的/etc/passwd、/etc/shadow、/proc目录、日志在/var/log/下、ss/netstat查端口、ps查进程。先把这些通用的搞扎实再学差异化的部分效率更高。2. 安全从业者必须练熟的Linux命令集我知道很多人一看到“命令大全”就头大觉得网上随便一搜一堆。但实际干安全命令不在于多在于你知道什么场景用什么命令、输出怎么解读。这里我不按教科书式的分类而是按一个真实排查场景的推进顺序来讲。2.1 信息收集先搞清楚系统里有什么拿到一台机器不管是要做基线检查还是应急响应第一步都是摸清家底。我常用的就这么几条uname -a # 内核版本、主机名、架构 cat /etc/os-release # 发行版信息 hostnamectl # 更详细的系统信息 uptime # 开机时间、负载如果开机时间很短要警惕是不是被重启过 last -n 20 # 最近的登录记录 cat /etc/passwd # 所有用户账号 ls -l /etc/shadow # 确认shadow文件权限是否正常别小看uptime这条我曾经在排查一台被入侵的机器时发现开机时间才几分钟但业务却显示运行了很久说明系统被重启过。再配合last reboot看重启记录就能确认是不是有人故意清理痕迹后重启或者内核提权之后被迫重启。/etc/passwd要怎么看重点看有没有UID为0的非root账号看有没有带shell的异常账号比如/bin/bash的账号应该是有限的尤其是那些home目录不是常规位置的账号。正常系统里带登录shell的账号基本都是系统管理员或者专门的应用账号多出来一个都值得查。2.2 进程排查找出“看起来正常”的异常进程进程排查是应急响应的核心环节。Linux下进程信息都在/proc目录里ps命令本质上是读取/proc再格式化输出。所以高级一点的排查直接看/proc反而更靠谱。先走一遍常规流程ps -ef # 全格式列出所有进程 ps aux # 带CPU、内存占用 top -c # 动态查看按CPU排序-c显示完整命令行 pstree -p # 看进程父子关系重点看几类可疑迹象进程名和路径对不上比如进程叫java但实际执行文件在/tmp下这基本可以判定有问号。CPU占用异常高但不属于业务进程挖矿脚本的典型特征但有些隐蔽的会把进程名伪装成kworker或者systemd。命令行里有base64编码、curl/wget下载、python -c这类特征的常见于 webshell 落地或者下载执行恶意代码。父进程关系混乱比如一个nginx worker的父进程不是master而是一个奇怪的PID这很可能被注入或者替换了。更深入一点用ls -l /proc/PID/exe看进程的可执行文件真实路径用readlink /proc/PID/cwd看进程的工作目录用cat /proc/PID/cmdline看完整命令行。如果某个进程的exe删掉了显示(deleted)说明攻击者运行了脚本后删掉了源文件这种更要小心。2.3 网络连接排查看它在和谁通信进程排查往下走必然要查网络连接因为恶意程序总要通信——要么回连C2要么对外扫描要么对内渗透。ss -antp # 查看所有TCP连接-p显示进程信息 ss -unap # UDP连接DNS外传和某些隧道常用UDP lsof -i :端口 # 查占用某个端口的进程 iptables -L -n # 查看防火墙规则-n不做域名解析s命令是现在的主流netstat很多新系统没装。ss -antp的输出里面有local address、peer address、process重点看那些发起到外部IP的连接尤其是目标端口是443、80、53以外的比如常见的C2端口以及连接状态是ESTABLISHED还是SYN_SENT。如果发现可疑连接别急着断开先确认进程是什么、有没有对应的文件、启动时间是什么时候。模拟过一次攻击场景在一台机器上发现了持续的HTTPS外连顺着进程找到了一个小脚本脚本里还写了连接服务器的地址和密钥信息这要是一上来就kill线索就断了。2.4 文件层面排查时间线是突破口攻击者无论做什么总要落地文件——脚本、二进制、webshell、日志清理工具。文件系统排查的核心是找时间线异常。find / -mtime -7 -type f # 最近7天修改过的文件 find /tmp -type f -ls # tmp目录全量列出很多攻击者喜欢用/tmp ls -lt /etc/ # 按时间排序看配置目录里最近改了什么 find / -name *.php -newer /etc/hostname -type f # 找某个时间点之后创建的php文件stat命令可以看文件的时间戳包括atime访问时间、mtime内容修改时间、ctime状态变更时间。注意ctime不是创建时间修改文件权限、属主、硬链接数都会改变ctime。对于排查来说三个时间都有用如果mtime和ctime相差很大可能文件被修改后被人为地把mtime改回去了这本身就是攻击痕迹。再配合ls -la看文件权限重点找SUID文件find / -perm -4000 -type f 2/dev/nullSUID文件意味着普通用户运行它时会以文件属主的权限执行如果攻击者能拿到一个有root权限的SUID程序就等于有了提权通道。正常系统里SUID文件应该是可以数的过来的多出任何一个都非常可疑。3. 系统加固哪些配置是真的有用的光会排查还不够安全是要把门关好的。加固是个大话题我不打算把CIS Benchmark的所有条目抄一遍只讲我在实际工作中验证过、真正挡过事的几项。3.1 账号与口令策略第一道防线很多人改密码只改长度要求实际上口令策略的关键在防暴力破解和防撞库。前面提到的/etc/login.defs是控制密码策略的地方PASS_MAX_DAYS 90 # 密码最长使用天数 PASS_MIN_DAYS 7 # 修改密码最小间隔 PASS_MIN_LEN 12 # 密码最小长度注意这只是个参考值但/etc/login.defs只对新建用户生效已有用户要用chage命令chage -M 90 用户名 chage -l 用户名 # 查看用户密码过期信息真正能挡暴力破解的是fail2ban或者自写的封禁脚本。fail2ban的原理就是监控日志文件发现某个IP在短时间内多次认证失败就丢进防火墙黑名单。我常用的配置是SSH模块maxretry 5bantime 3600监控/var/log/auth.log或者/var/log/secure。有的人觉得密码够复杂就行其实不然。密码再复杂也架不住键盘记录器或者钓鱼所以在有条件的情况下SSH建议直接走密钥登录并禁密码。需要注意禁用密码登录前一定要测试密钥能不能用。我见过不止一次有人在没测试的情况下把PasswordAuthentication no写进sshd_config然后重启SSH自己也被关在门外。稳妥做法是生成密钥、把公钥放到authorized_keys、测试密钥登录成功之后再禁用密码登录。3.2 SSH与远程管理安全SSH是服务器的主要入口也是被盯得最紧的攻击面。除了密钥登录还有几个配置值得改PermitRootLogin no # 禁止root直接登录管理员用普通用户sudo Protocol 2 # 只用SSHv2协议 MaxAuthTries 3 # 单次连接最大认证尝试次数 AllowUsers 用户名 # 白名单登录用户 ClientAliveInterval 300 # 客户端空闲检测间隔 ClientAliveCountMax 2 # 空闲超时最大次数超过则断开AllowUsers这个配置特别好用直接在sshd层面限制谁能登录其他人连尝试的机会都没有。对于固定管理员的服务器这比任何密码复杂度都有效。还有一点容易忽略sshd的监听地址。如果管理网段是固定的ListenAddress直接绑定到内网IP别让SSH暴露在公网。很多云上环境有安全组规则这个应该配合做而不是只依赖操作系统层面。3.3 权限与文件系统少给一点是一点Linux的权限模型看起来简单但实际用好的不多。UMask默认是022创建的文件是644目录是755。安全要求高的建议默认改成027甚至077这样新文件只对属主开放组内和其他用户都不可读。umask 027在/etc/profile里改一下新用户登录就自动生效。但要注意改成027后如果团队成员共用一个账号查看文件可能因为权限不够而报错需要配合合理的目录授权来用。sudo权限也要细看。很多系统为了省事直接把某个用户加进wheel组相当于给了sudo的权力。实际上可以更精确地控制只允许跑特定命令。用户 ALL(ALL) /usr/bin/systemctl restart nginx这样即使用户被拿下他能做的也极其有限。当然这种方式维护成本稍高适合关键业务服务器。3.4 防火墙与网络层封装iptables和firewalld之间怎么选我的建议是能上nftables/nft的新系统就直接用nftables规则表达能力强而且性能好老系统用iptables也没问题关键是规则要清晰可维护。举个例子如果服务器只提供Web服务那么外网进来的流量就只该访问80和443端口其他端口对公网不开放iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT iptables -A INPUT -j DROP这组规则看着简单但很多人一开始容易犯的错误是没有那第一条ESTABLISHED规则导致正常的回包流量也被DROP掉然后整个服务不可用。有了ESTABLISHED规则出去访问外部的连接响应就能正常进来要特别注意。生产环境改防火墙规则前建议先加一条定时任务或者用at定时关掉放行规则防止规则写错把自己锁死。我自己的习惯是改iptables前先iptables-save /root/iptables.bak出问题直接restore。4. 日志分析与入侵痕迹追踪从日志里读出故事日志是安全从业者最重要的“现场”很多攻击事件如果日志保留完整还原攻击路径并不难。但日志分析最怕的就是——该记的没记记了的看不懂看得懂的不知道该看什么。4.1 日志体系先知道什么东西记在哪里Linux系统的日志主要归systemd-journald和rsyslog管。journald负责收集内核和systemd产生的日志rsyslog把日志按优先级写到/var/log/下对应的文件。CentOS/RHEL系/var/log/secure认证相关日志SSH登录、sudo执行都在这里。/var/log/messages通用系统日志。/var/log/cron定时任务执行的日志。Ubuntu/Debian系/var/log/auth.log对应RHEL系的secure。/var/log/syslog对应messages。/var/log/kern.log内核日志。在有systemd的系统中journalctl也很好用journalctl -u sshd # 查看sshd服务的日志 journalctl -u nginx --since 2024-01-01 --until 2024-01-02 journalctl -k # 只看内核日志生产环境建议把journald的持久化打开默认是内存模式重启就丢了。改/etc/systemd/journald.conf里的Storagepersistent然后systemctl restart systemd-journald。4.2 登录日志解析谁在试图进你的系统SSH暴力破解是最常见的攻击行为登录日志能直接看到攻击者的来源IP、尝试的用户名、时间线。看SSH日志我一般这么做# 列出认证失败的前10个IP grep Failed password /var/log/secure | awk {print $11} | sort | uniq -c | sort -nr | head -10 # 列出成功的登录记录 grep Accepted password /var/log/secure | awk {print $1,$2,$3,$9,$11} # 检查sudo执行记录 grep sudo /var/log/secure | tail -50有一类攻击很典型用常见用户名弱密码的字典跑SSH比如root、admin、test、oracle这类名字。如果你在日志里看到某个IP尝试了成百上千次且用了一堆不同的用户名那基本可以断定是扫描器在跑字典。登录成功但来源IP可疑的情况更严重可能意味着已有账号被爆破。这时候要看从该IP登录成功的会话持续了多久、执行过什么命令。last命令能列出登录历史包括来源IP和登录时长。但要小心攻击者可能会清空/var/log/wtmp文件如果发现这个文件被清掉了本身就是入侵证据。4.3 命令历史看完这个就知道攻击者干了什么.bash_history文件对应急响应的重要性怎么强调都不过分。虽然老练的攻击者会清掉历史但并不是所有攻击者都这么细心。很多时候从历史里能直接看到攻击者的完整操作链下载了什么工具、改了哪个目录、添加了哪个用户。cat /root/.bash_history cat /home/用户名/.bash_history但要注意不是所有操作都记录在历史里。攻击者可能用unset HISTFILE禁用记录或者用其他shell绕过。另外如果攻击者通过Web漏洞执行命令webshell命令不一定经过shell历史这时候要结合Web日志和进程日志交叉看。如果目标是取证级别的排查建议用auditd来记录命令执行。auditd是内核级别的审计框架配置好之后所有命令都会被记录到/var/log/audit/audit.logauditctl -a always,exit -F archb64 -S execve -k command_log这样即便用户清空了bash历史audit日志里仍然保留着execve调用的记录。当然auditd本身也会成为攻击者的目标所以它产生的日志最好同步到远程日志服务器。4.4 找到日志被清理的痕迹攻击者清理日志有几种常见方式删除日志文件、修改关键日志内容、停止rsyslog服务、替换日志工具。排查时可以看看这些# 日志文件是否存在且大小合理 ls -l /var/log/secure* # 日志中是否有大段的时间跳跃 awk $1$1 /var/log/secure | tail -500 | head -5 # syslog服务是否在跑 systemctl status rsyslog systemctl status systemd-journald # 日志轮转配置是否被改过 cat /etc/logrotate.conf | tail -20有一种比较隐蔽的操作是攻击者只删除和自己相关的日志行比如用sed把某个IP的所有日志行删掉。这种痕迹表面看不出来但如果日志文件中间出现了明显的时间不连续比如16:00直接跳到18:00就要警觉。5. 常见排查问题速查与实操心得最后把我在实战中遇到的高频问题整理成一张速查表配合一些排查思路方便照着操作。现象可能原因排查命令/操作CPU持续100%挖矿程序或异常业务进程top -c找高CPU进程ls -l /proc/PID/exe确认路径内存被占满恶意程序常驻或日志爆满free -h、ps aux --sort-%mem检查/var/log大文件端口不明原因开放后门程序监听端口ss -antp查监听端口对应的进程系统莫名重启内核崩溃或被攻击者触发last rebootjournalctl -b -1 -e看上次启动前的日志登录异常缓慢SSH被爆破或DNS解析慢tail -f /var/log/secure观察临时加UseDNS no文件变成只读权限被篡改或文件系统异常ls -la看权限chattr i可能被加上了定时任务异常被写入后门定时任务crontab -l、cat /etc/crontab、ls /etc/cron.*网络连接大量外联数据外传或C2回连ss -antp统计外联IPstrace跟踪进程行为关于crontab -l还有一点要提醒很多攻击者不只写在当前用户和root的crontab里还会写在/etc/cron.d/、/etc/cron.hourly/等位置。所以排查定时任务要全盘看cat /etc/crontab ls -la /etc/cron.d/ ls -la /etc/cron.hourly/ ls -la /etc/cron.daily/ ls -la /etc/cron.weekly/ ls -la /var/spool/cron/crontabs/再说一个我在模拟项目X里总结的经验判断文件是否被篡改最简单有效的方式是事后对比。前提是你在系统正常时记录过文件的hash。把常用的二进制文件/bin/ls、/bin/ps、/usr/sbin/sshd等的hash存一份基线比如sha256sum /bin/ls /bin/ps /usr/sbin/sshd /root/file_baseline.txt以后排查时重新计算一遍一对比就知道哪些文件被替换过。这个方法不复杂但很多团队都没有做真出事的时候就只能靠经验猜了。最后聊一个很多人忽略的点时钟同步。日志分析非常依赖时间戳如果服务器的时间不准或者系统时间和日志时间差了几小时还原攻击路径时会非常痛苦。建议所有服务器都配好NTP同步并且把时区统一。排查问题前先看一眼date和timedatectl确认时间和时区是否正确。写在后面给重新出发的人一点建议我个人在实际排查中的体会是Linux系统的安全能力说到底是“了解程度”的比拼。攻击者能进来是因为他比你更了解系统的弱点和特性你能守住是因为你比攻击者更清楚系统里每个文件、每个进程、每条日志的正常状态。多折腾、多记录、多复盘才是提升Linux安全手感的路子。如果有条件自己搭一套靶场环境每天花点时间在上面做排查训练遇到真实事件的时候就不会慌。这个系列后面我还会继续写其他专题包括Web服务加固、数据库安全、应急响应流程之类的内容。你如果有什么特别想看的方向欢迎在评论区聊聊。 前阵子有个老同事打电话问我说现在想从运维转安全该从哪捡起来。我愣了一下想起自己十年前从运维岗离开兜兜转转又回了网络安全这条线确实有不少话可以说。这个系列写到第四篇前面聊了网络基础、渗透思路、防御体系的搭建这篇专门说说Linux系统——不管你是刚入行做安全运维还是搞渗透测试、应急响应Linux都是绕不开的底盘。十年前我做运维的时候天天跟CentOS 6、iptables、LNMP环境打交道那时候觉得Linux就是个跑服务的操作系统稳定、抗造、能扛并发就行。现在重新回到安全行业再看Linux视角完全不一样了同样是看一个系统以前关心的是服务怎么跑起来、资源够不够用现在关心的是这个系统有没有被入侵过、哪些地方可以被利用、日志里藏着什么线索。这篇就把我重新捡起Linux之后的一些实操经验整理出来包括安全视角下的基础巩固、常用排查命令、加固实操、日志分析还有一些踩过的坑。内容不会太基础但也不会一上来就甩内核源码适合有一定Linux操作经验、刚转安全方向或者做安全运维想系统梳理一遍的朋友。1. 安全视角下的Linux和运维视角有什么不一样先说我自己的体会。当年做运维Linux在我眼里是这样一个东西装好系统配好IP部署Nginx、MySQL、PHP然后写监控脚本盯着负载和磁盘出问题就上去重启服务或者调参数。那时候最怕的是半夜磁盘满了或者某个进程把CPU吃满业务告警。重新回到安全行业再看同一台Linux服务器问题就变成了另外一副面孔开放的端口是不是必要的系统里有没有可疑的账号某个二进制文件是不是被人动过手脚日志里那些登录失败的IP是不是在暴力破解一个文件的时间戳为什么和它周围的文件对不上这两种视角的差异本质上是从“让系统干活”变成了“审视系统的一切行为”。十年前我可能一个月都看不了一次last命令的输出现在几乎是排查问题的第一站。1.1 先放下运维时候的惯性思维运维出身的人有个特点遇到系统异常第一反应是“服务挂了赶紧拉起来”。但安全视角要求你多问一句服务是怎么挂的是不是被人搞挂的如果是被人搞挂的是怎么进来的进来之后干了什么现在还在不在这不是矫情而是实际教训。我之前处理过一个模拟项目X的应急事件某台测试服务器上的Web服务莫名其妙重启了运维同事直接systemctl restart完事。结果第二天又挂了排查才发现是被人上传了定时任务每隔几分钟就拉一次恶意脚本。如果第一次异常时就查一下crontab -l和最近的文件变更根本不用折腾两天。所以做安全第一步就是改掉“重启解决问题”的毛病。系统异常先别急着操作先保留现场、收集信息再决定怎么处理。这不是说运维习惯不好而是目标不同运维要的是恢复业务安全要的是搞清楚发生了什么。1.2 熟悉发行版差异但别被差异带偏国内服务器用CentOS/Rocky/Alma这系的多也有不少Ubuntu/Debian。做安全你需要熟悉它们的差异但不至于被差异困住。举几个实际会遇到的差异包管理yum/dnf对应apt装软件、查已装软件包的命令不同。服务管理现在基本都是systemd但有些老系统还是init脚本service和systemctl都要会。用户与组useradd的参数略有差异Ubuntu默认会创建home目录CentOS需要加-m。防火墙CentOS/Rocky默认是firewalldUbuntu默认是ufw底层都是iptables/nftables但命令差异很大。文件路径/etc/sysconfig/network-scripts/是RHEL系的网络配置Debian系是/etc/network/interfaces当然现在NetworkManager用得更多了。我建议在安全排查的时候先问一句“这是什么发行版”再动手。之前见过有人拿着CentOS的思维去改Ubuntu的网络配置折腾半天没生效其实人家用的是netplan配置文件在/etc/netplan/下。这种问题不涉及多高深的技术纯粹是对系统不够熟。但另一方面很多核心的东西是跨发行版一致的/etc/passwd、/etc/shadow、/proc目录、日志在/var/log/下、ss/netstat查端口、ps查进程。先把这些通用的搞扎实再学差异化的部分效率更高。2. 安全从业者必须练熟的Linux命令集我知道很多人一看到“命令大全”就头大觉得网上随便一搜一堆。但实际干安全命令不在于多在于你知道什么场景用什么命令、输出怎么解读。这里我不按教科书式的分类而是按一个真实排查场景的推进顺序来讲。2.1 信息收集先搞清楚系统里有什么拿到一台机器不管是要做基线检查还是应急响应第一步都是摸清家底。我常用的就这么几条uname -a # 内核版本、主机名、架构 cat /etc/os-release # 发行版信息 hostnamectl # 更详细的系统信息 uptime # 开机时间、负载如果开机时间很短要警惕是不是被重启过 last -n 20 # 最近的登录记录 cat /etc/passwd # 所有用户账号 ls -l /etc/shadow # 确认shadow文件权限是否正常别小看uptime这条我曾经在排查一台被入侵的机器时发现开机时间才几分钟但业务却显示运行了很久说明系统被重启过。再配合last reboot看重启记录就能确认是不是有人故意清理痕迹后重启或者内核提权之后被迫重启。/etc/passwd要怎么看重点看有没有UID为0的非root账号看有没有带shell的异常账号比如/bin/bash的账号应该是有限的尤其是那些home目录不是常规位置的账号。正常系统里带登录shell的账号基本都是系统管理员或者专门的应用账号多出来一个都值得查。2.2 进程排查找出“看起来正常”的异常进程进程排查是应急响应的核心环节。Linux下进程信息都在/proc目录里ps命令本质上是读取/proc再格式化输出。所以高级一点的排查直接看/proc反而更靠谱。先走一遍常规流程ps -ef # 全格式列出所有进程 ps aux # 带CPU、内存占用 top -c # 动态查看按CPU排序-c显示完整命令行 pstree -p # 看进程父子关系重点看几类可疑迹象进程名和路径对不上比如进程叫java但实际执行文件在/tmp下这基本可以判定有问号。CPU占用异常高但不属于业务进程挖矿脚本的典型特征但有些隐蔽的会把进程名伪装成kworker或者systemd。命令行里有base64编码、curl/wget下载、python -c这类特征的常见于 webshell 落地或者下载执行恶意代码。父进程关系混乱比如一个nginx worker的父进程不是master而是一个奇怪的PID这很可能被注入或者替换了。更深入一点用ls -l /proc/PID/exe看进程的可执行文件真实路径用readlink /proc/PID/cwd看进程的工作目录用cat /proc/PID/cmdline看完整命令行。如果某个进程的exe删掉了显示(deleted)说明攻击者运行了脚本后删掉了源文件这种更要小心。2.3 网络连接排查看它在和谁通信进程排查往下走必然要查网络连接因为恶意程序总要通信——要么回连C2要么对外扫描要么对内渗透。ss -antp # 查看所有TCP连接-p显示进程信息 ss -unap # UDP连接DNS外传和某些隧道常用UDP lsof -i :端口 # 查占用某个端口的进程 iptables -L -n # 查看防火墙规则-n不做域名解析s命令是现在的主流netstat很多新系统没装。ss -antp的输出里面有local address、peer address、process重点看那些发起到外部IP的连接尤其是目标端口是443、80、53以外的比如常见的C2端口以及连接状态是ESTABLISHED还是SYN_SENT。如果发现可疑连接别急着断开先确认进程是什么、有没有对应的文件、启动时间是什么时候。模拟过一次攻击场景在一台机器上发现了持续的HTTPS外连顺着进程找到了一个小脚本脚本里还写了连接服务器的地址和密钥信息这要是一上来就kill线索就断了。2.4 文件层面排查时间线是突破口攻击者无论做什么总要落地文件——脚本、二进制、webshell、日志清理工具。文件系统排查的核心是找时间线异常。find / -mtime -7 -type f # 最近7天修改过的文件 find /tmp -type f -ls # tmp目录全量列出很多攻击者喜欢用/tmp ls -lt /etc/ # 按时间排序看配置目录里最近改了什么 find / -name *.php -newer /etc/hostname -type f # 找某个时间点之后创建的php文件stat命令可以看文件的时间戳包括atime访问时间、mtime内容修改时间、ctime状态变更时间。注意ctime不是创建时间修改文件权限、属主、硬链接数都会改变ctime。对于排查来说三个时间都有用如果mtime和ctime相差很大可能文件被修改后被人为地把mtime改回去了这本身就是攻击痕迹。再配合ls -la看文件权限重点找SUID文件find / -perm -4000 -type f 2/dev/nullSUID文件意味着普通用户运行它时会以文件属主的权限执行如果攻击者能拿到一个有root权限的SUID程序就等于有了提权通道。正常系统里SUID文件应该是可以数的过来的多出任何一个都非常可疑。3. 系统加固哪些配置是真的有用的光会排查还不够安全是要把门关好的。加固是个大话题我不打算把CIS Benchmark的所有条目抄一遍只讲我在实际工作中验证过、真正挡过事的几项。3.1 账号与口令策略第一道防线很多人改密码只改长度要求实际上口令策略的关键在防暴力破解和防撞库。前面提到的/etc/login.defs是控制密码策略的地方PASS_MAX_DAYS 90 # 密码最长使用天数 PASS_MIN_DAYS 7 # 修改密码最小间隔 PASS_MIN_LEN 12 # 密码最小长度注意这只是个参考值但/etc/login.defs只对新建用户生效已有用户要用chage命令chage -M 90 用户名 chage -l 用户名 # 查看用户密码过期信息真正能挡暴力破解的是fail2ban或者自写的封禁脚本。fail2ban的原理就是监控日志文件发现某个IP在短时间内多次认证失败就丢进防火墙黑名单。我常用的配置是SSH模块maxretry 5bantime 3600监控/var/log/auth.log或者/var/log/secure。有的人觉得密码够复杂就行其实不然。密码再复杂也架不住键盘记录器或者钓鱼所以在有条件的情况下SSH建议直接走密钥登录并禁密码。需要注意禁用密码登录前一定要测试密钥能不能用。我见过不止一次有人在没测试的情况下把PasswordAuthentication no写进sshd_config然后重启SSH自己也被关在门外。稳妥做法是生成密钥、把公钥放到authorized_keys、测试密钥登录成功之后再禁用密码登录。3.2 SSH与远程管理安全SSH是服务器的主要入口也是被盯得最紧的攻击面。除了密钥登录还有几个配置值得改PermitRootLogin no # 禁止root直接登录管理员用普通用户sudo Protocol 2 # 只用SSHv2协议 MaxAuthTries 3 # 单次连接最大认证尝试次数 AllowUsers 用户名 # 白名单登录用户 ClientAliveInterval 300 # 客户端空闲检测间隔 ClientAliveCountMax 2 # 空闲超时最大次数超过则断开AllowUsers这个配置特别好用直接在sshd层面限制谁能登录其他人连尝试的机会都没有。对于固定管理员的服务器这比任何密码复杂度都有效。还有一点容易忽略sshd的监听地址。如果管理网段是固定的ListenAddress直接绑定到内网IP别让SSH暴露在公网。很多云上环境有安全组规则这个应该配合做而不是只依赖操作系统层面。3.3 权限与文件系统少给一点是一点Linux的权限模型看起来简单但实际用好的不多。UMask默认是022创建的文件是644目录是755。安全要求高的建议默认改成027甚至077这样新文件只对属主开放组内和其他用户都不可读。umask 027在/etc/profile里改一下新用户登录就自动生效。但要注意改成027后如果团队成员共用一个账号查看文件可能因为权限不够而报错需要配合合理的目录授权来用。sudo权限也要细看。很多系统为了省事直接把某个用户加进wheel组相当于给了sudo的权力。实际上可以更精确地控制只允许跑特定命令。用户 ALL(ALL) /usr/bin/systemctl restart nginx这样即使用户被拿下他能做的也极其有限。当然这种方式维护成本稍高适合关键业务服务器。3.4 防火墙与网络层封装iptables和firewalld之间怎么选我的建议是能上nftables/nft的新系统就直接用nftables规则表达能力强而且性能好老系统用iptables也没问题关键是规则要清晰可维护。举个例子如果服务器只提供Web服务那么外网进来的流量就只该访问80和443端口其他端口对公网不开放iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT iptables -A INPUT -j DROP这组规则看着简单但很多人一开始容易犯的错误是没有那第一条ESTABLISHED规则导致正常的回包流量也被DROP掉然后整个服务不可用。有了ESTABLISHED规则出去访问外部的连接响应就能正常进来要特别注意。生产环境改防火墙规则前建议先加一条定时任务或者用at定时关掉放行规则防止规则写错把自己锁死。我自己的习惯是改iptables前先iptables-save /root/iptables.bak出问题直接restore。4. 日志分析与入侵痕迹追踪从日志里读出故事日志是安全从业者最重要的“现场”很多攻击事件如果日志保留完整还原攻击路径并不难。但日志分析最怕的就是——该记的没记记了的看不懂看得懂的不知道该看什么。4.1 日志体系先知道什么东西记在哪里Linux系统的日志主要归systemd-journald和rsyslog管。journald负责收集内核和systemd产生的日志rsyslog把日志按优先级写到/var/log/下对应的文件。CentOS/RHEL系/var/log/secure认证相关日志SSH登录、sudo执行都在这里。/var/log/messages通用系统日志。/var/log/cron定时任务执行的日志。Ubuntu/Debian系/var/log/auth.log对应RHEL系的secure。/var/log/syslog对应messages。/var/log/kern.log内核日志。在有systemd的系统中journalctl也很好用journalctl -u sshd # 查看sshd服务的日志 journalctl -u nginx --since 2024-01-01 --until 2024-01-02 journalctl -k # 只看内核日志生产环境建议把journald的持久化打开默认是内存模式重启就丢了。改/etc/systemd/journald.conf里的Storagepersistent然后systemctl restart systemd-journald。4.2 登录日志解析谁在试图进你的系统SSH暴力破解是最常见的攻击行为登录日志能直接看到攻击者的来源IP、尝试的用户名、时间线。看SSH日志我一般这么做# 列出认证失败的前10个IP grep Failed password /var/log/secure | awk {print $11} | sort | uniq -c | sort -nr | head -10 # 列出成功的登录记录 grep Accepted password /var/log/secure | awk {print $1,$2,$3,$9,$11} # 检查sudo执行记录 grep sudo /var/log/secure | tail -50有一类攻击很典型用常见用户名弱密码的字典跑SSH比如root、admin、test、oracle这类名字。如果你在日志里看到某个IP尝试了成百上千次且用了一堆不同的用户名那基本可以断定是扫描器在跑字典。登录成功但来源IP可疑的情况更严重可能意味着已有账号被爆破。这时候要看从该IP登录成功的会话持续了多久、执行过什么命令。last命令能列出登录历史包括来源IP和登录时长。但要小心攻击者可能会清空/var/log/wtmp文件如果发现这个文件被清掉了本身就是入侵证据。4.3 命令历史看完这个就知道攻击者干了什么.bash_history文件对应急响应的重要性怎么强调都不过分。虽然老练的攻击者会清掉历史但并不是所有攻击者都这么细心。很多时候从历史里能直接看到攻击者的完整操作链下载了什么工具、改了哪个目录、添加了哪个用户。cat /root/.bash_history cat /home/用户名/.bash_history但要注意不是所有操作都记录在历史里。攻击者可能用unset HISTFILE禁用记录或者用其他shell绕过。另外如果攻击者通过Web漏洞执行命令webshell命令不一定经过shell历史这时候要结合Web日志和进程日志交叉看。如果目标是取证级别的排查建议用auditd来记录命令执行。auditd是内核级别的审计框架配置好之后所有命令都会被记录到/var/log/audit/audit.logauditctl -a always,exit -F archb64 -S execve -k command_log这样即便用户清空了bash历史audit日志里仍然保留着execve调用的记录。当然auditd本身也会成为攻击者的目标所以它产生的日志最好同步到远程日志服务器。4.4 找到日志被清理的痕迹攻击者清理日志有几种常见方式删除日志文件、修改关键日志内容、停止rsyslog服务、替换日志工具。排查时可以看看这些# 日志文件是否存在且大小合理 ls -l /var/log/secure* # 日志中是否有大段的时间跳跃 awk $1$1 /var/log/secure | tail -500 | head -5 # syslog服务是否在跑 systemctl status rsyslog systemctl status systemd-journald # 日志轮转配置是否被改过 cat /etc/logrotate.conf | tail -20有一种比较隐蔽的操作是攻击者只删除和自己相关的日志行比如用sed把某个IP的所有日志行删掉。这种痕迹表面看不出来但如果日志文件中间出现了明显的时间不连续比如16:00直接跳到18:00就要警觉。5. 常见排查问题速查与实操心得最后把我在实战中遇到的高频问题整理成一张速查表配合一些排查思路方便照着操作。现象可能原因排查命令/操作CPU持续100%挖矿程序或异常业务进程top -c找高CPU进程ls -l /proc/PID/exe确认路径内存被占满恶意程序常驻或日志爆满free -h、ps aux --sort-%mem检查/var/log大文件端口不明原因开放后门程序监听端口ss -antp查监听端口对应的进程系统莫名重启内核崩溃或被攻击者触发last rebootjournalctl -b -1 -e看上次启动前的日志登录异常缓慢SSH被爆破或DNS解析慢tail -f /var/log/secure观察临时加UseDNS no文件变成只读权限被篡改或文件系统异常ls -la看权限chattr i可能被加上了定时任务异常被写入后门定时任务crontab -l、cat /etc/crontab、ls /etc/cron.*网络连接大量外联数据外传或C2回连ss -antp统计外联IPstrace跟踪进程行为关于crontab -l还有一点要提醒很多攻击者不只写在当前用户和root的crontab里还会写在/etc/cron.d/、/etc/cron.hourly/等位置。所以排查定时任务要全盘看cat /etc/crontab ls -la /etc/cron.d/ ls -la /etc/cron.hourly/ ls -la /etc/cron.daily/ ls -la /etc/cron.weekly/ ls -la /var/spool/cron/crontabs/再说一个我在模拟项目X里总结的经验判断文件是否被篡改最简单有效的方式是事后对比。前提是你在系统正常时记录过文件的hash。把常用的二进制文件/bin/ls、/bin/ps、/usr/sbin/sshd等的hash存一份基线比如sha256sum /bin/ls /bin/ps /usr/sbin/sshd /root/file_baseline.txt以后排查时重新计算一遍一对比就知道哪些文件被替换过。这个方法不复杂但很多团队都没有做真出事的时候就只能靠经验猜了。最后聊一个很多人忽略的点时钟同步。日志分析非常依赖时间戳如果服务器的时间不准或者系统时间和日志时间差了几小时还原攻击路径时会非常痛苦。建议所有服务器都配好NTP同步并且把时区统一。排查问题前先看一眼date和timedatectl确认时间和时区是否正确。写在后面给重新出发的人一点建议我个人在实际排查中的体会是Linux系统的安全能力说到底是“了解程度”的比拼。攻击者能进来是因为他比你更了解系统的弱点和特性你能守住是因为你比攻击者更清楚系统里每个文件、每个进程、每条日志的正常状态。多折腾、多记录、多复盘才是提升Linux安全手感的路子。如果有条件自己搭一套靶场环境每天花点时间在上面做排查训练遇到真实事件的时候就不会慌。这个系列后面我还会继续写其他专题包括Web服务加固、数据库安全、应急响应流程之类的内容。你如果有什么特别想看的方向欢迎在评论区聊聊。