1. 重新拿起抓包工具同样的数据包完全不同的解读方式离开运维行业快十年再回到网络安全这行最强烈的感受不是技术更迭有多快而是——同样一个数据包十年前我看它和现在看它完全是两个世界的东西。当年做运维抓包排障是基本功。某个应用响应慢了接口报错了我先看链路通不通再看端口通不通接着抓包看握手有没有完成重传率高不高。那时候脑子里想的是“连通性”和“性能”看的是三次握手、窗口大小、RTT这些指标。数据包对我来说是排障的线索只要它能顺畅地从A点到B点我的工作就结束了大半。可现在站在安全视角重新看同一个数据包问题完全变了。我首先想的是这个连接是谁发起的它的目的端口为什么是445而不是80这个HTTP请求里为什么带着一段十六进制编码的字符串DNS查询的域名为什么像一串随机字符后面跟着一个看起来正常的根域名这些在过去会被我直接略过的“边缘信息”现在恰恰是攻击者在网络里留下的脚印。之所以说应用层协议是重新入行者的第一站是因为今天的攻击几乎都发生在应用层。十年前做运维时我们防的是外部扫描、端口探测防火墙一挡感觉就安全了。但现在的威胁模型完全不同攻击者不需要打得穿防火墙只需要在一个合法的HTTP请求里藏一段恶意载荷在一个正常的DNS查询里夹带数据在一条看似无害的HTTPS连接里执行远程指令。防火墙放行80和443是因为业务需要而攻击者就顺着这些“必须开放”的口子进来了。所以这篇文章我不会去背协议标准。我更想从“一个干了十年运维、刚转回安全的人”的视角说说重新理解应用层协议时那些真正改变我思维方式的东西以及在实际分析和溯源工作中这些协议细节是怎么被用起来的。如果你也是从运维、开发这类“建设方”角色转来做安全这篇文章应该能帮你省下不少自己摸索的时间。2. 为什么说应用层是安全的主战场绕开系统层直捣业务层2.1 从三次握手到七层模型运维知识没有白费但需要换一种使用方法很多人觉得转行安全要“忘掉过去重学”我反而不这么看。运维底子不仅不浪费而且是安全分析里非常稀缺的能力。关键在于换一个角度去用它。当年调试链路问题我脑子里有完整的TCP状态机SYN_SENT、SYN_RCVD、ESTABLISHED、FIN_WAIT……这套东西在分析安全事件时依然好用。比如看到大量SYN包发出去却没有回应第一个反应可能是“这机器被扫了”或者是“有程序在尝试外连”。再往下追就要看是谁发起的、目标是什么端口、源端口有什么规律这些全都要回到传输层的基础上来分析。但安全工作和运维有一个根本区别运维的目标是让流量“正常跑起来”安全的目标是判断流量“正不正常不正常到什么程度”。运维关注的是协议“按标准工作”安全关注的是协议“有没有被歪用”。同一个HTTP头运维确认格式对不对安全分析则要追问这个User-Agent常见吗这个Content-Type和实际内容匹配吗这个Cookie的值为什么长度异常这就是我前面说的“换一种使用方法”。TCP/IP的基础知识是你的地基但在安全领域你真正要精耕的是地基之上那个最复杂、最多变、最容易被滥用的部分——应用层。2.2 应用层为什么是攻击者的“舒适区”攻击者不是随机选择攻击层的他们选应用层有非常现实的原因。第一应用层暴露面最大。任何对外开放的业务系统Web界面、API接口、邮件服务、文件共享全都跑在应用层。你能在防火墙后面藏住一个IP但藏不住业务本身——一个面向用户的网站就必须让全世界都能访问到443端口。第二应用层的数据结构最复杂。TCP层的数据是一段字节流而应用层要把这段字节流拆解成有意义的请求、响应、命令、参数。这个“拆解”的过程就是攻击者做手脚的地方。多一个参数、编码方式换一下、请求方法改一下解析结果就会完全不同。第三应用层协议是“人写得最多写错也最多”的地方。操作系统内核有几十年沉淀很难出低级漏洞但业务代码是每个公司自己写的水平参差不齐。一个开发者写的登录接口可能连基本的输入过滤都没做。我在实际排查中见过太多这样的案例某公司自己的系统明明只该接收JSON请求却有人用multipart/form-data的方式提交了一个登录表单然后在文件名字段里塞了一段命令。如果只看IP层、TCP层这段流量和正常请求毫无区别。只有在应用层解析之后恶意意图才会暴露。这就是为什么我们说“安全的主战场在应用层”——因为攻击在这里最省力、成功率最高、手段最多样。而防御方要做的就是把每一层协议的“正常情况”吃透才能第一时间发现那些“不太对劲”的流量。3. 三个必须吃透的应用层协议HTTP、DNS、FTP/SMB3.1 HTTP/HTTPS最庞大的攻击面也是最练功的协议如果要给应用层协议的重要性排个序HTTP/HTTPS毫无争议排第一。今天的Web攻击、API攻击、爬虫、数据泄露几乎都绕不开HTTP。先说说HTTP本身。它是纯文本协议加密的是TLS层HTTP本身的结构没变请求行、请求头、请求体三个部分每部分都有文章可做。请求行里最直观的就是方法。GET、POST之外PUT、DELETE、OPTIONS、PATCH这些不太常用的方法经常被忽略但往往是问题所在。我之前分析过一个事件内部某台服务器对外发起大量请求特征就是用了DELETE方法访问一个公开API而且每次删除之后都会立刻重新PUT一个新值。如果只看“有没有流量外传”这个问题根本发现不了但当你在HTTP层观察“方法序列不合理”异常就浮出来了。请求头是另一个高发区域。User-Agent是重灾区。扫描器、恶意脚本、自动化工具都有特征明显的UA这也是很多WAF做拦截的基础。但也有攻击者故意伪装成浏览器UA这时候光看UA就不够了要结合行为特征——一个声称是Chrome的UA却保持着每秒20个请求的频率明显就不合理。请求体则是注入类攻击的藏身处。SQL注入、命令注入、反序列化攻击很多都隐藏在POST请求的body里。我学到的一个重要经验是不要只看参数名和值要看参数的类型和结构。一个正常的id123和一个id1 OR 11格式上完全不一样。这也是“内容安全”和“流量安全”的分界线——只在网络层做防护根本看不到这层差异。再说HTTPS。加密流量是今天所有安全分析人员绕不过去的坎。十年前做运维时我只需要知道证书没过期、握手能成功就够了。现在做安全加密流量里藏着大部分的攻击行为看不穿就只能靠其他手段做侧写——比如连接时长、数据包大小分布、TLS握手指纹。TLS握手指纹是个好东西。简单说每个TLS客户端在握手中提交的密码套件列表、扩展项顺序都不太一样这些信息的组合可以形成一个“指纹”用来识别这个客户端是什么软件。常见的开源库、恶意软件都有自己独特的指纹。在这上面我吃过亏一开始只盯着解密流量忽略了对握手阶段的分析结果漏掉了一个疑点——后来才意识到攻击者根本不需要等加密内容被解出来光握手就能暴露身份的一部分。3.2 DNS看似简单的协议却能干很多“大事”DNS可能是应用层协议里最不起眼的一个但恶意软件最爱用它。DNS的流量特征是数据包不大、UDP传输、查询频繁。企业网络里默认就允许内网机器访问外部DNS服务器。攻击者利用的正是这份“默认信任”。最典型的是DNS隧道。原理不复杂把想传的数据拆成小块编码进DNS查询的域名里比如你要传的数据.某个公网域名接收方在自己的DNS服务器上记录查询日志再把数据拼回去。这个过程从网络侧看只是无数条DNS查询完全淹没在正常流量里。很多公司防火墙拦截了所有非标准端口的外连但唯独放行UDP 53因为业务查询域名总要解析——DNS隧道就顺着这个口子出去了。我自己做过一次实验在一个只放行DNS和HTTP外连的环境里用现成的DNS隧道工具传一个几MB的文件。结果网络侧几乎没有任何告警只有一台专用服务器上的查询日志记录了所有数据分片。这个实验给我留下的印象极深——它说明如果一个安全团队连DNS流量都不监控就相当于在自己门口留了一条小路专门供人搬运东西。除了隧道DNS还用来做僵尸网络的指令下发。恶意软件定期向某个域名发起查询频率像心跳一样。域名的含义对人类来说毫无意义但对恶意软件却是一个“约定好的信号”。我在分析一个内网异常时靠的就是发现一台机器每过5分钟查询一个由随机字符构成的域名后来确认是某种下载器的回连行为。所以做安全分析DNS必须重视。不是说要把每个查询都抓下来分析而是要对“异常的域名结构”“异常的查询频率”“异常的解析结果”保持敏感。3.3 FTP与SMB时代遗留的协议仍然是内网渗透的经典入口如果说HTTP是外网攻击的主战场那FTP和SMB就是内网渗透的老路。FTP这个协议我太熟悉了早年运维时传文件基本靠它。它最大的弱点在哪里控制信道和数据信道分离。FTP用一个21端口做控制另一个随机高位端口做数据传输。防火墙往往只放行了21端口但实际数据连接跑在随机端口上——于是出现了“控制通了数据传不了”这种运维经典问题。这个特性在安全上同样是个漏洞攻击者可以通过FTP的PORT命令让FTP服务器向任意IP和端口发起连接造成所谓的FTP反弹攻击。一个处于内网的FTP服务器可以被外部攻击者当作“跳板”去扫内网其他主机。SMB则是Windows网络共享的核心协议。当年运维中我见到SMB就像见到空气一样自然——打印机、文件共享、组策略下发全都跑在它上面。可它的历史包袱非常重早期版本为了兼容留下了大量复杂的消息类型和机制这也让SMB成为远程漏洞的重灾区。更重要的是SMB天生是“内网协议”它假设内网是可信的。一旦攻击者拿到了内网的任何一台机器SMB就成了他们横向移动最顺手的工具枚举共享、尝试弱口令、利用漏洞执行远程代码。我在一次内网应急里复盘过一个感染链路入口是某台服务器上的Web漏洞攻击者拿到权限后没有急着外传数据而是先用SMB枚举整个网段的共享资源找到一台设置了弱口令的文件服务器然后通过计划任务横向跳了过去。整个过程全是“正常功能”的调用——共享访问、文件拷贝、计划任务创建。没有一次使用漏洞没有一次使用越权行为纯粹就是靠协议功能本身做坏事。这就是FTP和SMB这类“老协议”的难防之处它们的功能设计是合法的但同样一批功能在不同的人手里可以变成完全不同的用途。安全人看协议除了看“怎么实现的”更得看“怎么被歪用的”。我整理了一个表格把这三个协议从“运维视角”和“安全视角”做对照方便转行的人快速建立思维转换协议运维关心的核心能力安全关注的核心风险HTTP/HTTPS连通性、响应时间、缓存策略注入、漏洞利用、恶意载荷、API滥用、数据窃取DNS解析速度、缓存命中率、可用性隧道外传、恶意域名回连、隐蔽通道、劫持FTP / SMB传输效率、鉴权配置、共享权限反弹链接、弱口令、横向移动、蠕虫传播与漏洞利用4. 应用层分析的实战方法从流量里看出“人味儿”4.1 把抓包工具用出安全分析的味道抓包工具还是当年那几款但用法已经完全变了。版本选型上命令行下的分析我用tcpdump抓原始包再用tshark做字段级过滤。图形界面我用Wireshark做深入交互分析。这里有个“从运维转安全”的人最容易犯的错抓包抓得太晚。做运维时一般是问题出现了才抓包抓到的往往只是问题发生后的后半段。做安全分析必须在可疑行为一开始就持续抓取、保留完整链路不然事后回溯时关键的第一跳流量早就没了。实际操作时我会先做粗过滤把总体流量跑一遍重点看以下信息# 统计所有IP对之间的会话量 tshark -r capture.pcap -q -z conv,ip # 只看HTTP请求带方法、URI和UA tshark -r capture.pcap -Y http.request -T fields \ -e http.request.method -e http.host -e http.uri -e http.user_agent # 只看DNS查询 tshark -r capture.pcap -Y dns.flags.response 0 -T fields \ -e dns.qry.name -e dns.qry.type这三条命令在过去排障时也会用但目的不同。现在我会特别关注“比例”——比如某个IP的请求方法几乎全是POST占99%以上正常业务POST占比高不是不可能但要看POST对应的URI是否集中在特定路径上。如果POST分散、GET极少、UA还各不相同这往往是自动化的扫描行为而不是真人操作。Wireshark的“Conversation过滤”和“Follow Stream”这段时间我用了特别多。Follow TCP Stream可以直接把一次会话的请求和响应拼成可读内容虽然HTTPS下看到的只是密文但HTTP下能直接看到整个对话过程。有一次分析某个被入侵的Web服务器就是这么一路Follow下来看到了攻击者通过一个命令执行漏洞在服务器上逐条输入命令的完整记录——从创建目录到下载工具再到关闭防火墙整个过程就像在眼前操作一样清晰。4.2 特征层面的倾斜正则、指纹与行为基线抓包看多了以后你会形成一种“流量直觉”——哪个IP不对劲哪个端口组合可疑扫一眼就知道。但这种直觉不能只靠感觉得沉淀成特征和规则。正则匹配是基础手段。比如HTTP响应中的报错信息很多注入类攻击在成功触发时会在响应里带上数据库报错内容。通过特征正则可以快速把所有疑似SQL注入的请求筛出来。但这个做法有明显局限只要攻击者稍加编码、分段、转换正则就会被绕过。指纹匹配是更高一层的手段。前面提到TLS握手指纹还有JARM指纹一种基于TLS服务器响应风格的指纹、HTTP头顺序指纹等。攻击者可以改UA、改载荷内容但很难完全抹掉自身工具的指纹特征——因为他们用的代码库、默认参数、加密套件偏好已经固化了。有一次一批攻击请求的UA伪装成了最新版本的浏览器但请求头里HTTP头部的顺序和那个版本浏览器的真实顺序不一致明显是从别处抄来的UA字符串贴在了错误的工具上。这类细节光看单个请求是发现不了的一对比就露馅。行为基线则是最高最难的一层。拉长时间窗口把一台主机连续几周的对外连接记录下来建立“它平时是什么样子”的基线。新出现的目标、异常的请求频率、奇怪的端口组合在这些基线面前都会显得刺眼。运维背景的人做这件事有天然优势我们本来就熟悉“正常的系统该长什么样”这个直觉放在行为基线里非常有价值。4.3 案例分析一段异常加密流量是如何被“扒开”的分享一个实际的排查过程不算特别复杂但很能说明问题。某天值班同事发现一台内网Linux服务器的带宽占用异常长时间维持在高速状态。一开始怀疑是有人下载大文件但从系统进程里找不到任何大流量进程CPU负载也不高。排到网络侧后发现占用带宽的是一批持续的加密TCP连接目标都是海外的一个IP端口是443。从传输层看一切“正常”——连接稳定、重传率低、收发对称。问题就出在“太正常”了。如果是业务请求请求量应该随着时间有明显波动但这台服务器的连接是恒定、匀速、7x24不间断的。正常的业务流量是人产生的人的活动有昼夜节律哪怕是自动任务也会有周期调整。而这种恒定连接更像是一台机器在按固定速率发送数据。接着往下钻。这批连接的TLS握手指纹不属于任何主流的操作系统或浏览器的表现——既不是Windows的Schannel也不是Linux的OpenSSL、Nginx、Apache等常见组合而是一个我们不认识的密码套件顺序。仔细核对后发现它指向的是一个开源的数据传输工具。为什么确认因为那个工具默认会启用一个特定扩展且顺序固定这个特征在正常浏览器里几乎不出现。最后通过DNS解析记录和对连接目标的资产信息分析确认这台服务器被植入了后门数据正在以加密流量的形式加密外传。整个过程没有解密任何HTTPS内容全靠握手指纹、行为特征和连接形态就完成了判别。这个案例给我们的启发很直接安全分析不能死磕“解不开密就没办法”。流量里除了加密部分还有大量明文元数据——连接时长、数据大小、频率、目标、TLS参数。这些信息配合起来往往已经足以形成高置信度的判断。5. 给回归者的应用层协议学习路线别上来就啃标准文档5.1 从抓包开始而不是从文档开始很多转安全的人一上来就去读RFC文档这个习惯我不太推荐。RFC是给实现者看的描述了“协议长什么样”但安全分析需要的是“协议在实际流量中长什么样”。这两者之间有不小的差距真实流量里各种厂商实现不规范、兼容性处理、私有扩展、反向代理改写都让流量形态比标准复杂得多。我的建议是反过来——先抓包再看文档。第一步抓一段自己的浏览流量。打开Wireshark访问一个普通网站把过程中的流量存下来。然后一条一条看哪些是DNS查询哪些是TCP握手哪些是TLS握手哪些是HTTP请求。你很快会发现一个页面加载会产生几十上百个请求每个请求都有完整的生命周期。这段经验是任何文档都给不了的。第二步带着问题去读文档。当你在流量里看到某个字段看不懂比如Accept-Encoding: gzip, deflate, br里的br是什么再去查RFC和相关资料。那个时刻的学习效率是最高的因为你有真实的例子在手上一查就懂一懂就能用。第三步主动制造异常流量。比如用curl向某个端口发一些非常规的请求看看服务器的响应有什么不同或者用一个简单的Python脚本发送畸形HTTP请求观察服务端会不会报错、会不会崩溃。这类主动探测能帮你快速建立“异常长什么样”的感觉。5.2 值得长期跟踪的“实验台”本地环境自建学习应用层协议安全最忌讳只看理论不实践。我建议花一晚上时间在本机建一个实验环境成本低、效果好。在本地用容器模拟一套业务系统一个Web服务负责登录和文件上传一个解析服务负责把数据加工后入库中间加一层Nginx做代理。然后分别从“正常用户”“攻击者”两个身份访问这条链路——正常用户就是打字访问攻击者则尝试在参数中拼接特殊字符、绕过上传后缀限制、以极端参数值触发服务端异常。做完这一步再用抓包工具把两边的流量分别存下来。你会发现正常请求和恶意请求在流量层面有明显差别。攻击者的请求大概率会带着探测性参数、非常规的Content-Type、额外的方法调用。这种“对照样本”做得越多你对恶意流量的敏感度就越高。也推荐平时多看看开源的安全测试工具生成的流量特征比如各种扫描器、渗透测试框架默认的请求长什么样。了解这些工具的指纹之后当你在真实流量里看到同款指纹就能立刻锁定攻击工具。5.3 常见误区清单转安全后最容易踩的坑结合我自己这两个月的经历列了几个转行过程中最容易踩的坑误区一什么都想抓什么都想存。存储永远是有限的全量抓包在企业环境里根本扛不住。要懂得分层留存短周期的全量抓包用于深度分析中周期的连接日志五元组、时间戳、字节数用于行为回顾长周期的告警事件用于战略分析。这个“分层”的思路我在运维时期就熟悉转到安全后依然适用。误区二只关注有没有“攻击特征”不关注“正常长什么样”。高级攻击者最擅长的就是藏进正常流量里去掉显著特征。如果你不知道正常的基线看到什么都会觉得“好像没问题”。建立行为基线是安全运营里最花时间但最值得做的事。误区三看到加密流量就跳过。加密不等于安全加密只是把内容藏起来了。还有很多非内容维度可以参考——证书的颁发史、JARM指纹、流量形态、连接模式都能提供分析线索。误区四忽略协议“被歪用”的可能性。这是从运维转安全最需要扭转的一点。运维思维是“协议是做这个用的”安全思维是“协议在这个场景下居然可以被这样用”。举个最简单的例子HTTP的TRACE方法正常情况下几乎没人用但它可以被用来做跨站追踪攻击。如果没有“歪用”的思维你会觉得所有TRACE请求都是噪音。6. 最后说几句掏心窝的话离开运维十年再回来我的一个深切的体会是技术变了思维方式也得跟着变但“底层逻辑”这东西是一通百通的。十年前我理解一台服务器靠的是进程、端口、日志、性能计数器现在理解一次攻击靠的是连接、协议、特征、行为模式。表面看是完全不同的知识体系骨子里都是同一件事——“通过可观测的信息还原藏在背后的真实活动”。做运维的还原的是业务异常做安全的还原的是恶意行为。这个底层能力十年前培养起来如今依然直接可用。如果你和我一样从运维、开发阵营转过来我建议你在应用层协议上多花点时间别急着去学那些花哨的攻防技巧。协议是流量分析的底层语言在这一层扎得越深后面做入侵分析、威胁狩猎、应急响应都会顺手很多。至于下一步的内容我打算往TLS协议和加密流量分析再走一步。目前手头正整理一批“看起来正常但实际可疑”的加密连接样本里面有不少有意思的细节。到时候写出来应该能做一些内容上的延伸。
