前两天帮一个朋友收拾一台被打过洞的服务器后台被塞了一个挖矿脚本CPU直接拉满。排查了整整一晚上最后的结论不是哪个0day漏洞而是三处极其基础、基础到很多人根本不会看一眼的配置问题SSH端口全网可连、站点管理接口直接暴露在公网、某个可写目录的权限配得过于宽松。Web服务器安全这个领域给人的第一印象往往是需要对抗顶级黑客、研究复杂攻击链但根据我个人处理过的这类案例十次被攻破有七八次都倒在入门知识点上而且栽的姿势基本一模一样。这篇文章是《Web服务器安全知识点简述》系列的第一篇把服务器层面最容易出问题、也最容易被忽略的安全地基过一遍包括攻击面收敛、最小权限模型、TLS配置、流量型攻击防护以及日志监控。适合刚接手服务器运维工作的新人也适合那些平时主要写业务代码、偶尔要自己管服务器的全栈工程师。我不打算堆一堆高深的漏洞利用细节而是把真正可落地的配置方法和判断逻辑讲透你看完就能拿这份清单去自查手上的机器。1. 安全基线为什么默认安装的服务器就是半个靶子所谓的安全基线不是说让你装多高级的安全设备而是先把那些默认存在的东西全部收紧。很多站点装完Web服务就直接把域名解析过来浏览器能打开页面就算上线了。这个流程里入侵窗口就已经被打开了不止一个。1.1 安装即暴露默认配置里的常见风险点第一个口子是默认端口和默认页面。不少建站套件在安装时会额外起一个管理端口常见的是8080、8888这类高位端口用来给用户提供一个图形化维护界面。问题在于这类端口在多数情况下会全局监听没有任何来源限制默认密码也往往还是第一次安装时随手设的弱口令。端口扫描器扫到端口再配合弱口令字典跑一遍收益高得惊人。第二个口子是默认后台路径。很多套件后台固定挂在某个路径上路径本身不算漏洞但如果后台不限制来源IP、不开启二次验证就等同于把管理钥匙挂在门口。我有一次在一个模拟项目X的环境里做测试装完某套件后默认后台路径直接是固定且可访问的登录页还标注了版本号等于主动告诉攻击者可以查哪些已知问题。第三个口子是测试文件。部分镜像会在网站根目录留下测试脚本、展示用的示例项目打开就能读到系统版本、绝对路径。这些文件看起来人畜无害但实际上等于主动把服务器底细交了出去。这三个问题有个共同点它们都不是需要深挖的漏洞而是暴露面与默认口令的组合拳。对攻击者来说扫一个常规端口然后尝试弱口令的成本比研究漏洞低太多成功率也高太多。安全基线的第一件事就是把这类额外暴露面全部清掉。具体做起来不复杂装完系统之后我会按下面这个顺序过一遍安装时选择最小化组件只勾选真正需要的功能不需要的一律不装检查监听端口看哪些端口在对外网提供服务逐条确认用途删掉自带的测试页面、示例站点和默认文档改掉所有默认账号密码不需要的默认账号直接禁用。这一套操作下来表面攻击面已经小了一大圈。别小看这一步我见过不少被攻破的服务器问题恰恰就出在一个没人记得的默认页面上。1.2 从端口扫描结果反推攻击面我一直觉得做安全加固前第一步不是盲目查漏洞而是搞清楚自己的机器对外到底敞开了哪些门。对一台新接手的服务器我会先从一个外部视角盘一遍开放端口不需要复杂工具眼下很多开源端口扫描器都能做到一条命令就能把结果列出来。有一台我接手过的线上机器当时扫出来的端口情况大概是这样的开放端口常见来源风险程度处置思路22SSH远程管理中只允许管理网段访问改用密钥登录80/443Web服务对外访问低必须保留保持配置干净8080面板或备用服务高若无公网需求绑定内网或直接移除3306数据库服务监听高立即关闭外网监听只留本地回环这张表我定期会对线上机器跑一遍重点关注那些不在预期内的端口。端口本身不是漏洞但每一个端口都意味着一个可交互的入口入口越多出问题的概率越大。数据库监听如果暴露在公网上配合弱口令就是灾难现场而8080这种端口往往是某些历史遗留服务偷偷跑着没人管。对于不在预期内的服务果断停掉、删掉别想着“以后可能还用得上”。最小化暴露原则在服务器安全里的地位和最小权限原则一样重要。2. 最小权限模型的落地运行身份、目录边界与模块裁剪最小权限是一个老生常谈的词落地到Web服务器上就是三个问题进程以什么身份运行、目录结构允许谁读写、服务模块到底装了哪些。绝大多数配置失误都出在这三处。2.1 工作进程为什么必须是无特权用户先从运行身份说。见过不少把Web服务进程直接以管理员权限跑的服务器理由是图省事、权限不够会报错。这个做法的问题在于攻击者如果能利用某个上传点拿到一句脚本后门这个后门就继承了进程的全部权限。以管理员权限运行时后续操作一路畅通写系统目录、改任务计划、装持久化后门全部不需要再提权。反过来如果进程以无特权的普通用户跑攻击者进来之后能动的东西极其有限最多在Web目录里折腾想再往上突破还得另找漏洞。同样是拿到一句话后门权限模型不同后续损失就是天壤之别。我处理过一个案例对方站点根目录权限过宽被塞了一个小后门文件结果攻击者利用Web账号直接改写了另一个相邻业务的静态资源影响范围比预期大得多。具体落地我建议分三步。第一步创建专用账号不要把普通的登录账号拿来跑服务也不要用系统默认的访客账号单独建一个不能登录系统的服务账号属于标准做法。第二步把主应用目录的读写权限按需分配程序文件由管理员账号拥有服务账号只有读权限。第三步在Web服务配置里明确指定运行身份。如果系统用的是现代服务管理机制还可以加上只读文件系统、禁止获取权限等加固选项。这些配置写起来都不难核心就是把进程的权限边界尽可能缩到最小。顺便说下模块裁剪。Web服务有很多可加载的功能模块有些是默认编译进来的但你的业务可能根本用不到。少一个模块就少一份被利用的风险。我个人的经验是编译安装时尽量静态编译不用的功能直接不装动态加载的模块也定期盘点一遍把长期不用的禁掉。有些人觉得模块放着不用就没风险但模块所在的代码路径不会凭空消失一旦对应的历史问题被公开扫描器就能立刻识别出来。2.2 目录读写分离与上传目录的执行隔离目录权限是另一个高频事故区。很多站点为了省事把整个网站根目录一次性地让Web服务账号可写这样做确实方便但也意味着任何一个通过业务漏洞拿到上传能力的攻击者都可以直接往根目录塞文件然后想办法让文件被当成脚本执行。这里的问题不在上传本身而在于存储和执行边界没有分开。合理的设计是读写分离。站点根目录里的大部分文件设为只读由管理员账号管理只有确实需要写入的目录比如上传目录、缓存目录才单独分配可写权限。对于上传目录还要再做一层执行隔离目录允许写入文件但不允许里面的文件被当作动态脚本执行。用一个常见配置来举例在Web主机的配置片段里加上这样一个规则表示对某个上传目录下的脚本类文件一律拒绝访问location ^~ /uploads/ { location ~* \.(php|php5|phtml|jsp|asp)$ { deny all; } }这一段配置的意思是上传目录仍然可以正常访问图片、压缩包等静态文件但一旦请求的是可执行脚本后缀就直接返回拒绝。攻击者即便把脚本传上去也没法在服务器上把它跑起来。注意这里的核心思想目录可以允许写入但绝不允许从该目录执行代码。常见错误是只改权限不关注文件类型。结果就是上传目录能写也能执行后门一传一个准。另一个容易忽视的细节是不要让Web服务账号同时拥有站点根目录和其他敏感目录的写权限。目录之间的边界一旦打通攻击者就可以从Web目录往别的目录拖文件。把这些边界在部署时定好后面能省掉大量麻烦。3. TLS配置证书之外还有一堆隐性陷阱现在说HTTPS。很多人觉得装个证书就算HTTPS了其实证书只是第一道门。我接手过的站点里有不少确实开着HTTPS但协议版本还保留着老旧的口子加密套件里也塞着已知强度问题的选项甚至有的证书链没配完整导致一部分用户访问时反复报安全隐患。这些都不算漏洞利用但问题级别一点不低。3.1 协议、套件与证书链三个高频事故现场第一个事故现场旧协议没禁掉。SSLv3以及TLS1.0、TLS1.1这些老协议都在历史上被验证存在可被利用的设计缺陷常见攻击手法是利用协议漏洞干扰加密流程让通信降级到更弱的加密状态。现在的浏览器基本已经不再允许这些老协议但服务器配置里它们可能依然开着。建议配置里只保留TLS1.2和TLS1.3其余协议直接关掉。第二个事故现场加密套件优先级不对。现代配置应该优先选择带前向保密能力的套件也就是使用临时秘钥交换的套件这样即使服务端私钥泄露历史流量也无法被回放解密。配置示例大概是这样ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers on; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!3DES; ssl_session_cache shared:SSL:10m;这类配置写法在主流开源Web服务器里通用具体语法稍有差异核心就是限制协议范围、抬高套件优先级。第三个事故现场证书链不完整。有些站点只上传了域名证书没有附带中间证书导致多数浏览器理解不了信任链直接弹出不受信任的提示。移动端应用对证书链尤其敏感不少App接口连不上就因为这个。装配证书时一定要把服务器证书和对应中间证书按顺序拼接成一个文件再配置配置完之后立刻用外部网络环境访问测一遍不要只在服务器本机测。再补一点易踩坑的证书续期。常见的免费证书生命周期通常只有90天很多站点就是忘记续期导致HTTPS直接报错。建议在自动化脚本里加上到期检查到期前主动提醒别等着浏览器报错再来查。另外还有HSTS。它能让浏览器强制使用HTTPS访问对防降级很有帮助。但HSTS里的“自带预加载”一旦开启生效后想撤销要等一个较长的周期。域名还没完全稳定、有切回HTTP需求的站点不要急着开预加载可以先只开普通HSTS。3.2 安全响应头便宜又容易被漏掉的一层另一类几乎零成本的加固是HTTP响应头。它们不涉及复杂的加解密度只是在每次页面返回时带上一组声明却能限制浏览器在处理页面时的默认行为。以下这些是基础配置里我基本都会加的Content-Security-Policy告诉浏览器页面允许加载哪些来源的资源如果攻击者想通过注入脚本从外部加载代码就会被这条规则拦下来X-Frame-Options: SAMEORIGIN声明页面不允许被其他站点用内嵌框架加载能减少点击劫持类攻击X-Content-Type-Options: nosniff禁止浏览器猜测文件类型避免服务器返回类型不明文件时被强行解析为可执行内容Referrer-Policy控制请求头里的来源信息携带策略减少访问路径、查询参数等信息外泄。示例组合大概是这样的Content-Security-Policy: default-src self; script-src self; object-src none; X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff Referrer-Policy: strict-origin-when-cross-origin这些响应头加上几乎不消耗性能但也可能误伤业务。最容易翻车的是CSP如果站点用了第三方统计、外部字体、CDN资源而CSP规则里没有放行这些域名页面上的资源会被全部拦掉显示出来就是缺样式、报错一大堆。经验做法是先别急着执行最严格策略而是把CSP先开成观察模式跑一段时间把被拦截的域名收集一遍确认没有影响业务后再逐步收紧。4. 面对流量型攻击基础限流能扛住什么攻击里最让人头疼的不是单个漏洞而是直接把服务器资源耗尽。这类流量型攻击在服务器端能做的其实是有限的但有一些基础配置不做会让服务器的扛击打能力掉一个数量级。这一节先说清楚哪些能自扛哪些必须求助外部。4.1 内核连接参数与请求速率限制的实际组合连接耗尽类攻击的目标是让服务器把资源全耗在处理无效连接上。最常见的手法是通过大量伪造的半开连接把连接表占满让正常用户连不上。应对这个问题的第一道防线在内核层开启SYN cookie后系统在连接队列溢出时能通过一种无状态机制来确认请求的合法性算是一种低成本高收益的缓解手段。相关内核参数建议这样设置net.ipv4.tcp_syncookies 1 net.ipv4.tcp_syn_retries 2 net.ipv4.tcp_max_syn_backlog 1024这里要说清楚这些参数并不是让机器变成铁桶而是让机器在高压力下不至于立刻瘫掉。真正的公平限制还要在业务入口层做限制单IP同时建立的连接数以及限制单IP单位时间内的请求速率。以常见入口配置为例可以抽象成两层限制第一层限制同一IP的并发连接数第二层限制单位时间内的请求速率整体写法类似这样limit_conn_zone $binary_remote_addr zoneconn_limit:10m; limit_conn conn_limit 20; limit_req_zone $binary_remote_addr zonereq_limit:10m rate10r/s; limit_req zonereq_limit burst20;这里主要表达的是两层意思同一来源IP在入口层同时建立的连接数有上限活跃请求过多时其他请求要排队等待。对绝大多数正常的浏览器用户来说这些阈值余量充足不会造成误伤但扫描器、恶意爬虫和低级的连接耗尽攻击会立刻显得非常吃力。阈值设定建议先放宽一倍观察几天再根据访问日志微调不要一上来就拍一个极限值。4.2 访问控制的分层思路白名单优先于黑名单做访问控制很容易陷入一个误区拼命收集恶意IP把黑名单越拉越长。坦白说黑名单只能挡住已知的攻击来源而攻击者换IP的成本极低。更好的思路是反过来以白名单为主以黑名单为辅把访问控制分成几个层次。第一层是网络层访问控制。防火墙规则只放行明确需要的端口管理端口只允许特定网段访问。这是最基础也最有效的一层。第二层是服务层访问控制。后台、管理接口这类敏感路径直接在Web服务配置里限定来源IP不在白名单内的网段一律拒绝。好处是即使网络层防火墙被绕过服务层还能兜底。第三层是自动化封禁。借助日志分析和封禁工具读取多次登录失败的记录超过阈值就把来源IP加入临时拒绝名单。这类工具实现成本很低适合中小站点。第四层是业务层控制。登录接口加上频率限制、验证码等机制避免批量撞库。四层配合下来效果比单靠任何一层强很多。另外补充一点真实踩过的坑有个业务站点曾经为图省事把海外IP段全部封掉结果一查后台发现有一大批海外华人用户正在正常使用当天就撤销了规则。封禁策略要跟业务形态配套不能拍脑袋。管理类入口必须白名单优先面向普通用户开放的业务封禁策略要谨慎尤其不要凭一时冲动封掉大片IP段否则误伤真实用户之后处理投诉的时间远比封禁省下的时间多。5. 日志与监控危机发生前就该做好的事最后聊聊日志和监控。我处理过不少事后排查的活最崩溃的情况是登录服务器一看日志要么没开要么被清空了只剩下一个被打得乱七八糟的现场。与其事后痛苦不如在部署当天就把日志这件无聊但重要的事做好。5.1 四类日志里最值得盯住的异常特征需要重点关注的日志我一般分成四类访问日志记录每个请求的来源IP、请求路径、状态码、请求头等信息。它是分析攻击行为的第一手材料。错误日志记录服务运行中发生的异常SQL语法错误、文件权限不足等都会在这里反映出来攻击尝试经常在错误日志里留下痕迹。认证日志记录所有登录行为尤其是SSH、管理后台的登录尝试。失败次数猛增是暴力破解的明确信号。应用日志按业务需要自行输出记录业务层的异常操作。这些日志的保留策略要提前定好别舍不得磁盘空间。备份归档加定期清理既保证出问题时能翻到又不会让日志文件无限膨胀。异常特征不用背记住几个高频套路就够了。第一单个IP在短时间内请求大量不存在的路径状态码一堆404多半是目录扫描。第二大量POST请求打到本来不需要接受数据的接口上可能有攻击者正在向目标提交恶意数据。第三同一个IP反复更换请求头完全不符合正常浏览器的习惯。第四请求路径里出现超长参数、编码混用或明显意外的文件后缀都要额外留意。光有日志不分析等于白存。最简单的分析方式就是先从访问日志里按状态码和来源IP做个聚合比如统计昨天返回404最多的前十个IP一条Shell命令就能跑出来awk $9 404 {print $1} /var/log/access.log \ | sort | uniq -c | sort -rn | head -20如果某个IP的404数量是其他正常用户的几十倍那个人大概率有问题值得再翻一下它的完整请求记录。5.2 用小型脚本先把告警跑起来监控也不一定非要上复杂的监控平台。小规模服务器用shell脚本加上定时任务就能覆盖绝大多数核心告警。你可以从这几个指标入手最近一段时间内认证失败的次数、最近一段时间内错误状态码的数量、磁盘使用率、系统负载。写一个脚本把每个指标统计出来超过阈值就发通知大概几十行代码就够。脚本逻辑不需要多花哨核心就是“统计—比较—触发”。例如#!/bin/bash LIMIT20 FAILED$(journalctl --since 10 min ago 2/dev/null | grep -c Failed password) if [ $FAILED -gt $LIMIT ]; then echo 检测到大量认证失败最近10分钟共 $FAILED 次 # 可以在这里追加通知逻辑 fi脚本能不能起作用关键在阈值怎么定。建议第一次上线时把阈值放得很宽比如允许10分钟内失败20次先把工具跑起来观察一周获取正常基线再逐步收紧。这里有个很现实的坑告警设置太灵敏每天给手机推几十条消息过不了两周人就会麻木最后真正出事时反而没人看。宁可先把阈值放粗、少打扰也不能让看监控的人产生告警疲劳。日志轮转也要定期检查避免一个文件涨到好几个GB后既影响读取又拖慢服务器。这些基础工作不酷但真到被攻击那一天的复盘里它们才是救命的关键。写到这里服务器侧的安全地基算是过了一遍。回顾我处理过的案例真正把网站搞挂的往往不是那些酷炫的高级手法而是攻击面没收紧、权限放太宽、日志没留底这类基础问题。你先把攻击面收敛、最小权限、TLS、访问控制和日志监控这五件事做扎实再谈那些更复杂的安全设备也不迟。这是系列的第一篇下一篇我打算把目光转向Web应用本身聊聊注入类攻击、跨站脚本这类应用层攻击在真实站点上是怎么被拦截的以及它们和服务器侧配置怎么配合。如果你有想优先听的话题可以留言告诉我我会根据反馈调整后面几篇的侧重点。