
搞安全的十个人里有九个半的入门路线都是从Kali Linux开始的。但说实话我见到太多人装完Kali就急着开MSF、跑sqlmap真到需要自己排查问题、分析日志、梳理进程的时候反而卡在这条命令什么意思为什么没有权限这种最基础的地方。这篇东西不是给你背命令手册的而是把我自己在Kali和Ubuntu以及日常当服务器用的各种Debian系环境上摸爬滚出来的经验做一次梳理。标题里的关键词命令、权限、进程、日志管理这四个东西本质上是安全从业者的四个手脚——命令是手权限是规矩进程是现场日志是脚印。搞清楚它们后面学渗透、做应急响应、搞等保测评才有地基不然全是在沙子上盖楼。无论你是刚装上Kali虚拟机的新手还是用Ubuntu当日常开发机想顺便把安全基础补上的同学这篇文章都适合你。我尽量说人话把每个操作背后的为什么也讲清楚看完你至少能自己动手查清楚一台Linux机器上发生了什么。1. 环境选择与准备为什么是Kali搭配Ubuntu而不是二选一很多人有个误区觉得学安全就直接上KaliUbuntu这种普通系统没必要碰。我的建议恰恰相反Kali负责输出Ubuntu负责理解。1.1 Kali和Ubuntu的真实定位差异Kali的底层其实也是Debian系和Ubuntu同宗同源包管理都是apt那一套。区别在于预装的东西完全不同。Kali默认给你塞了六百多个安全工具从信息收集到漏洞利用、从无线破解到密码爆破应有尽有。这个开箱即用对新手是双刃剑——你确实省了装工具的麻烦但也正因为太省事了很多人根本不知道工具跑起来的时候系统底层发生了什么。Ubuntu恰恰相反它更像一张白纸。你装完系统之后得自己去敲apt install自己去配置服务自己去折腾各种权限问题。这个过程看起来绕远路实际上是把Linux的底子给你磨扎实了。我在带人入门的时候特别喜欢让他们先在Ubuntu上手动折腾一遍LAMP或者LNMP全程不用一键脚本。等他们能说清楚为什么mysql进程跑在mysql用户下为什么/www目录要设置成750的时候再回到Kali里用各种工具思路完全不一样。1.2 资源有限时的推荐搭建方案如果你是学生党或者只有一台电脑我的建议是先装VMware或者VirtualBox然后在虚拟机里装一个Ubuntu作为日常工作学习的主力虚拟机Kali作为备用虚拟机两台都配好快照。不用追求物理机装Kali。99%的安全学习场景里面虚拟机的性能损耗完全可以接受而且快照功能真的是后悔药——把Kali玩坏了回滚一下两秒钟的事。配置方面我给个参考内存宿主机16G以上时给Kali分4GUbuntu分4G剩下留给宿主系统。磁盘Kali给60GUbuntu给80G都选动态分配。网络默认NAT模式就行等学到内网渗透那一课再换桥接也不迟。装系统本身没什么好说的Ubuntu一路Next就行。Kali要注意一点安装时选择图形化安装时记得自定义分区不要让安装器全盘自动分区否则后面做双系统或者扩容的时候会很痛苦。另外强烈建议不要用root账户作为日常登录账户——这一点后面权限章节会细说。1.3 第一件必做的事配好更新源和快照装完系统第一件事不是装工具是换软件源。国内默认源慢得要死换成国内镜像源之后apt的速度能快一个数量级。操作不复杂在/etc/apt/sources.list里把源地址换成你所在网络环境访问快的镜像站然后sudo apt update一下。配好源之后趁系统还是干净的立刻打个快照。后面你拿Kali去扫靶机、跑exp、装各种乱七八糟的工具指不定哪一下就把系统搞挂了。有快照兜底恢复成本几乎为零。2. 命令行基本功不是会敲命令而是会组合命令命令行这个东西看起来是死记硬背实际上核心是两件事第一知道系统里有哪些命令能帮你找到答案第二把多个命令用管道符串起来形成一条流水线。绝大部分Linux用得好的人并不是记住了几百条命令而是熟练掌握了查找-过滤-处理这一套组合逻辑。2.1 文件与目录操作的高频组合ls -lah而不是光秃秃的ls。-l看权限和属主属组-h人性化显示大小-a看隐藏文件。安全排查的时候隐藏文件往往是线索重灾区。find /path -name *.conf -type f这种用法非常高频。它的真正威力在于-exec参数比如找到所有带SUID权限的文件find / -perm -4000 -type f 2/dev/null这条命令在安全审计里可以说是必用。grep是另一个核心。grep -r password /etc/直接递归搜索整个配置目录。配合-n显示行号、-i忽略大小写查配置、查日志效率翻倍。我特别想强调一下grep的-A、-B参数grep -A 5 Failed password /var/log/auth.log这条命令能显示匹配行之后的5行内容。看登录日志的时候光看失败行没用得看看后面跟了什么比如是不是同一个IP在反复尝试暴力破解。这就是组合的价值。2.2 文本处理三件套awk、sed、sort、uniq很多新手看到awk和sed就头大觉得像天书。其实可以这样理解awk是按列处理文本的sed是按行处理和替换文本的sort加uniq是做统计去重的。举一个非常实战的例子分析Web服务器的访问日志想看看哪些IP访问次数最多一条命令搞定awk {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20这段的意思是取第一列默认空格分割IP就是第一列排序统计每个唯一值的出现次数按次数从大到小排取前20条。如果你手动去翻日志找恶意的IP翻到天亮都翻不完用这条组合命令三秒出结果。sed的经典用法是批量替换sed -i s/old_password/new_password/g /etc/config.conf。注意-i是直接修改原文件小白建议先不加-i跑一遍看看输出再动手。2.3 vim和系统信息查看是另一块拼图在服务器上没有图形界面编辑配置文件基本全靠vim。别怕刚开始只需要记住几个操作就能活下来i进入插入模式开始编辑Esc退出编辑模式:wq保存退出:q!不保存退出。/keyword在文件里搜索关键字按n跳下一个。dd删除当前行yy复制当前行p粘贴。系统信息查看命令也需要背熟。df -h查磁盘剩余空间、free -h查内存使用、uptime看负载。特别是uptime输出的load average三个值如果持续大于CPU核心数说明系统负载很高得去看看是不是有进程在作妖。这个点在后面讲进程排查时会展开。我的建议是不要死记硬背把下面这条体检组合存成别名或者直接抄在小本本上uname -a cat /etc/os-release df -h free -h uptime一条命令拿到系统版本、磁盘、内存、负载的全貌。排查问题的时候先跑这条心里有个底。3. 权限管理安全体系的根基也是最容易翻车的地方Linux的权限模型设计得其实很精巧但在实际使用中我看到太多人因为图省事直接把权限拉满或者全程用root操作。这么说吧凡是出过安全事故的机器十台有八台能在权限配置里找到低级错误。3.1 对rwx和数字权限的彻底理解我们知道每个文件都有一个属主owner、一个属组group和其他人others每类角色分别对应读r4、写w2、执行x1三种权限。数字表示法的逻辑就是把这三种权限的值加起来7421就是读写执行642就是读写541就是读执行。chmod 644 file的意思一目了然所有者为6读写属组为4只读其他人为4只读。写配置文件的场景里644是常规操作。chmod 755则是所有者有全部权限组和其他人有读和执行权限这是目录和脚本最常见的权限配置。但有一条铁律我要反复强调不要随便用chmod 777。777意味着任何人可读可写可执行对于Web目录里的上传文件、临时目录来说这等于给攻击者开了一扇门。我自己见过太多案例一个chmod 777 -R /var/www/html下去整个网站源码随意被篡改数据库配置文件直接被拖走。需要写权限的时候把写权限只给到属主或者用下面要讲的ACL精确控制都比777强一百倍。3.2 属主和属组的概念以及chown的正确用法chown user:group file用来修改文件的属主和属组。注意普通用户通常只能改自己拥有的文件的属组改属主需要root权限。这个限制是有意为之的否则谁都把文件改成root的系统就乱套了。一个典型的应用场景是你部署一个Nginx服务页面文件本来是root所有的但Nginx的worker进程跑在www-data用户下就需要把Web目录的属主改成www-data或者把属组改成www-data。chown -R www-data:www-data /var/www/html就是干这个的。如果属主和NGINX进程用户不一致就会出现权限拒绝的报错——这个坑很多新手都踩过。3.3 umask新文件默认权限的幕后黑手umask决定了你新建文件或目录时的默认权限。它的逻辑是从默认的最大权限里扣掉哪些权限。文件默认最大权限是666目录是777。如果umask是022那么新建文件的权限就是666-022644目录是777-022755干净又安全。如果非要图方便把umask改成000那新建的文件默认就是666任何人都能改你的文件。对于安全要求高的场景建议把umask设置为027甚至077这样组内其他人和其他用户默认就没有任何权限。3.4 特殊权限位SUID、SGID、Sticky Bit的安全隐患这几个概念在面试中常年出现更重要的是在真实排查中它们往往是漏洞的来源。SUID数字4开头比如4755。它表示执行这个文件时临时获得文件属主的权限。系统里有几个程序确实需要SUID才能正常工作比如/usr/bin/passwd——普通用户需要临时以root身份修改/etc/shadow。但如果攻击者把一个恶意二进制文件设置了SUID root然后诱导你执行他就直接拿到root权限了。所以安全检查时find / -perm -4000 -type f查出来的SUID文件列表需要逐一过目多出来的可疑项就是大问题。SGID数字2开头比如2755。表示执行时获得文件属组的权限在目录上设置SGID后子文件/子目录会继承该目录的属组。协作开发环境下经常用到。Sticky Bit数字1开头典型的是/tmp目录权限为1777。它的作用是即使目录是777普通用户也只能删除自己创建的文件不能删别人的。没有Sticky Bit的共享目录会乱成一锅粥谁都能删别人的临时文件。3.5 用户和用户组管理权限最小化的落地方式权限管理落到实操上核心就是最小化三个字。不要图省事直接把用户加进sudo组而是应该精确分配。创建用户用useradd -m -s /bin/bash username加sudo权限的方法是编辑/etc/sudoers文件注意一定要用visudo命令这个命令会做语法检查直接改文件容易写错导致sudo全部失效那就尴尬了。只允许某个用户执行特定命令在sudoers里可以这样写username ALL(ALL) /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx这个写法限定了该用户只能用sudo重启和查看nginx状态其他sudo操作一概拒绝。权限最小化的好处是即使账户密码泄露攻击者的操作范围也被限制在一定边界内。还有一个非常常见的问题是公司可能有多个运维共用一个root密码出事了根本查不出来是谁执行的。正规一点的做法是每个运维都有自己的账户需要root权限时用sudo并输入自己的密码这样日志里每条sudo记录都能对到人。4. 进程管理一台机器健不健康看一眼进程表就知道进程是系统运行的最小现场单元。排查性能瓶颈、发现入侵痕迹、干掉卡死的服务全都离不开进程管理。很多时候安全事故的第一现场就藏在进程列表里。4.1 从ps到top再到htop观察入口的选用最基础的进程查看是ps -ef全格式显示所有进程和ps aux以BSD风格显示所有进程并带CPU和内存占用。二者的区别是显示格式不同看个人习惯但ps aux默认显示资源使用率排查的时候更直观。如果想动态看系统实时状态用top。top界面上半部分是系统负载、任务数、CPU和内存的总览下半部分是实时刷新的进程列表。按P按CPU排序按M按内存排序这两个快捷键要刻进肌肉记忆。如果你嫌top的界面不够友好装一个htop它的交互界面彩色直观可以直接用方向键选进程、F9杀进程对新手非常友好。sudo apt install htop一行命令的事强烈推荐。4.2 定位CPU飙高和内存泄漏的完整排查路径这是一个实战频率极高的问题服务器CPU飙到100%或者内存被吃光怎么查第一步用top进去按P让进程按CPU使用率排序看一眼是哪个进程吃满了CPU。如果有明显的可疑进程名比如一串随机字母马上记下PID。第二步用ls -l /proc/PID/exe查看这个进程对应的可执行文件路径真实的命令路径会在这里暴露。如果它指向/tmp或者其他异常目录基本可以判定是恶意进程。第三步用ls -l /proc/PID/cwd查看进程的工作目录也能提供线索。第四步cat /proc/PID/cmdline查看启动参数看它是怎么被拉起来的。内存方面的排查也类似top按M排序看内存占用。如果按了内存排序看到某个进程占了几个G然后用pmap -x PID看这个进程的详细内存分布或者用cat /proc/PID/status里的VmRSS字段看真实物理内存占用。内存泄漏类问题往往表现为进程时间越跑占用越高重启一下恢复正常过一段时间又涨上去这时候就得去翻应用的日志找泄漏点了。4.3 进程的信号、kill与杀不死的僵尸进程手动终止进程用的是kill命令本质是给进程发信号。kill PID默认发SIGTERM也就是请求它正常退出。kill -9 PID发的是SIGKILL内核直接强制终止进程没有任何机会清理资源。日常推荐先用默认的SIGTERM等几秒没退再用-9直接-9容易留下一堆子进程没人管。比kill更灵活的是pkill可以根据进程名匹配比如pkill -f python3 app.py会把完整命令行里包含python3 app.py的进程都杀掉。还有一类很常见的故障叫僵尸进程。特征是ps里的状态列是Z你杀不掉它因为僵尸进程本来就死了只是父进程没有调wait回收它。处理方法是把僵尸进程的父进程解决掉让init进程PID为1接管回收。具体就是ps -o ppid -p 僵尸PID查父进程PID然后kill掉那个父进程僵尸进程就会被清掉。如果父进程是init也就是1僵尸会一直挂在那个PID下只能重启系统解决——不过一般系统里挂几十个僵尸也不是大问题不用过度紧张。4.4 端口与进程的对应是排查网络问题的必修课很多安全场景需要知道哪个端口被哪个程序占用了耳朵里经常听到的这机器上好像开着什么服务就得靠命令来确认。ss -tlnp可以列出所有监听状态的TCP端口以及对应的进程。-t只看TCP-l只看监听状态-n不反解域名显示数字端口-p显示进程PID和名称。老系统没有ss可以用netstat -tlnp效果一样。如果发现一个完全不该存在的端口在监听比如一个8484端口先看PID然后按前面讲的通过/proc/PID查路径。这是安全应急里最频繁的操作之一。5. 日志管理机器自己会说话关键看你听不听得懂Linux系统最让我喜欢的一点是它会把几乎所有重要事件记录下来。日志就是系统给管理员留下的行车记录仪。安全审计也好、故障排查也罢日志都是第一手的证据来源。5.1 /var/log下的核心日志文件地图不同发行版的日志路径略有差异但在Debian系Ubuntu和Kali都是里基本就认这几个日志文件记录内容/var/log/syslog系统整体日志包括各种服务启动信息/var/log/auth.log认证与授权日志登录、sudo操作都在这里/var/log/kern.log内核日志驱动报错、硬件问题看这里/var/log/dmesg内核环形缓冲区信息开机时的硬件识别记录/var/log/syslog很多服务默认输出的日志/var/log/btmp记录失败的登录尝试二进制格式用lastb查看/var/log/wtmp记录成功的登录记录二进制格式用last查看安全排查里最常翻的是auth.log。想看看有没有人在暴力破解SSH直接grep Failed password /var/log/auth.log | awk {print $11} | sort | uniq -c | sort -rn这段命令把认证失败日志里的IP挑出来统计一眼看出是不是有某个IP在疯狂尝试。如果你发现某个IP尝试了几百上千次基本可以确定为暴力破解处理方式是防火墙封掉这个IP同时建议直接关闭密码登录改用密钥登录。5.2 journalctl现代系统日志的统一入口从Ubuntu 16.04开始systemd成为了默认的init系统配套的journald接管了大部分日志收集功能。它的好处是统一的二进制格式存储还带索引查询效率非常高。最常用的几条journalctl -xe查看最近的错误信息-x附加说明-e直接跳到末尾排错时的第一选择。journalctl -u nginx.service只看nginx这个服务单元的日志。journalctl --since 1 hour ago只看最近一小时的日志。journalctl -f类似tail -f持续输出新日志调试时特别好用。注意journald的日志是二进制存储的直接在/var/log/journal里翻是没有意义的必须用journalctl命令查询。5.3 日志轮转与磁盘空间保护日志如果不处理能活活把磁盘塞满。好在系统默认有logrotate工具按天/周/月轮转日志并保留指定数量的历史档。配置文件在/etc/logrotate.d/目录每个服务一个配置文件比如nginx的配置可能是这样/var/log/nginx/*.log { daily rotate 7 compress delaycompress missingok notifempty create 640 www-data adm }含义是每天轮转一次保留7份旧日志旧的压缩存储新日志权限640且属主是www-data。有自定义应用日志的时候跟着这个模板写一个配置文件扔到/etc/logrotate.d/里就行不用自己写脚本删日志。我遇到过一种情况某天数据库磁盘满了全库只读业务直接瘫痪。查了半天发现是应用日志一年没轮转单个日志文件几十个G。所以检查根分区使用率的时候看到/var占用巨大第一反应应该是去看日志文件大小日志目录里du -sh /var/log/*跑一下就清楚了。5.4 日志被清空时的痕迹判断安全应急里还有一个不能忽略的知识点攻击者拿到权限之后为了抹除痕迹往往会清理日志。/var/log/auth.log空了甚至整个/var/log目录都空了一大半。看到这种情况本身就是一个强信号——说明机器可能已经被入侵了攻击者正在清理现场。当然日志被清空不代表无迹可循。有几个地方攻击者往往注意不到history命令的记录是用户的清掉很容易但root执行过的shell命令可能已经在auditd日志里只要系统开启了auditd。bash的进程残留、临时目录里的文件、shell启动脚本.bashrc、.bash_profile里被插入的恶意命令这些都是常见线索。数据库的binlog、应用自身的运行日志、甚至防火墙的NAT日志都可能留下攻击者的痕迹。所以做应急响应的时候不要只盯着auth.log一个一个看要有全局审阅的意识——从进程查起从启动项查起从定时任务crontab查起日志只是其中一个信息来源而已。6. 综合实战一条完整的异常排查链路前面几块内容单独拎出来都很基础但真实场景里这些东西是要串起来用的。我在这里放一条我常用的排查链路完全是个人经验按这个顺序走大部分服务器好像被人搞了的报警都能有个初步结论。第一步先看进程表和负载。运行uptime看负载运行top按CPU排序。如果发现有可疑进程按前面说的ls -l /proc/PID/exe查路径cat /proc/PID/cmdline看启动参数。第二步检查网络连接和端口监听。ss -tlnp看本机监听了哪些端口有可疑端口立刻记下PID。第三步查登录记录。last -20看最近登录的人lastb -20看暴力破解的来源IP。第四步看认证日志。tail -100 /var/log/auth.log重点看有没有异常时间点的登录、有没有sudo提权记录。第五步检查计划任务。crontab -l看当前用户的定时任务cat /etc/crontab看系统级别的定时任务还要翻/etc/cron.d/目录。攻击者非常喜欢通过定时任务实现持久化这个点往往是最容易发现马脚的。第六步检查开机启动项。systemctl list-unit-files --stateenabled列出所有开机自启的服务看看有没有不认识的。这条链路跑下来心里基本有个数了。我测试过很多次哪怕是一个刚上手的同学照着这个顺序查也能在十分钟内定位到90%以上的常见异常。剩下的10%就涉及日志分析更深的层面比如拿Web日志做全部IP的画像、对比正常流量基线的异常流量那是专门的威胁分析方向了。7. 写在最后的几点实在建议把基础打牢前期慢一点后面反而快。我真见过简历上写着精通Kali的人连chmod和chown都说不利索这种人到了实际项目里第一个站出来顶锅的就是他。反过来如果你能在Ubuntu上把一个服务从部署到排错、从权限到日志都理顺再回来看Kali里那些工具你会发现它们不过是一层壳底层全是这四样东西命令、权限、进程、日志。现在就可以动手做的事打开你的虚拟机用free -h看一下内存用ss -tlnp看一下当前监听了哪些端口再tail -50 /var/log/auth.log看看最近的认证日志。走完这三条你心里对自己系统的底数会比大多数人清楚得多。以后想进阶往容器安全、云安全这些方向走这套Linux基础永远都在发挥作用。