网络安全基础

1 网络安全基础要建立的防线

网络安全首先要回答的是：哪些主体可以通过什么路径，对哪些资源执行什么操作，以及异常发生后怎样发现并限制损失。连接能够建立，只能说明当前路径允许通信，不能说明请求者可信、进程没有漏洞或文件不会被误改。运维中的安全目标，要同时落到网络连接、运行进程、账号权限、文件数据和恢复能力上。

本课使用一个小型 Linux 环境贯穿说明：入口区的网关接收 HTTPS 请求，服务区运行应用，数据区保存数据库与备份，管理区提供运维入口。示例地址使用私有网段，文档中的命令应在自己的练习环境执行。应用进程使用专用账号，配置文件由管理员维护，数据库只接收指定服务来源。这里的业务可以是内部文档或监测面板，安全推理不依赖某种业务剧情。

要保护的性质包括机密性、完整性与可用性。机密性要求未授权者看不到文件和通信内容；完整性要求未经许可的修改能被阻止或发现；可用性要求正常用户在约定条件下能使用服务。备份文件被读取、配置被篡改、连接被耗尽，分别突出不同风险，但同一次事件也可能破坏多个目标。只关注“有没有人偷数据”，就会漏掉误操作和资源耗尽。

防线应沿实际访问路径安排。网络入口限制可达端口，主机检查本地连接，服务验证身份，进程只获得必要文件权限，日志记录关键事件，备份承担恢复。各处控制的职责要清楚：防火墙可以拒绝连接，却无法判断所有应用操作是否合理；文件权限能限制进程读写，却不能保证被允许读取的内容不会被滥用。不同控制共同缩小失败范围。

例如，服务进程需要读取 /etc/demo/app.conf，不代表它需要修改这个文件；需要连接数据库，也不代表它需要访问备份目录。把这些区别写成可检查的条件，安全工作就从“尽量加固”变成了“允许哪些行为、如何验证、失败怎样收敛”。后面每节都围绕这组条件展开。

2 威胁模型、资产与攻击面

威胁模型是对风险条件的简明描述。先列资产，再列可能接近资产的主体，最后描述可利用的入口与后果。资产不只有数据库，还包括管理员的 SSH 凭据、应用配置、备份、日志、服务可用时间，以及能够修改安全规则的管理接口。日志若与应用一起被删除，事故调查也会失去依据，因此日志本身同样需要保护。

攻击者可以是只能访问公网入口的陌生人，也可以是已经控制某个服务账号的人。误操作人员、配置错误和失效设备也会导致安全目标受损。建立模型时要说明起点，例如“假设服务区的应用进程已被控制，但攻击者尚未取得管理员权限”。这个假设不是断言漏洞一定存在，而是让我们检验：入口失守后，其他控制还能保住哪些资源。

攻击面指可能被接触并触发行为的接口。监听端口、远程管理入口、上传目录、可执行脚本、共享文件夹都属于检查对象。在 Linux 主机上，ss -lnt 能查看监听的 TCP 地址和端口；有权限时，ss -lntp 还能显示相关进程。输出中的 127.0.0.1:5432 表示绑定本机回环地址，0.0.0.0:5432 表示监听本机所有 IPv4 地址，后者是否能被远程访问还要结合路径和过滤规则判断。

进程身份需要另查。可以用 ps -eo pid,user,args 查看进程账号与启动参数，再用 id demoapp 查看专用账号所属组。命令行可能包含敏感信息，观测结果也应按权限保存。一个普通账号若加入能够读取备份的组，即使没有管理员权限，也可能拿到关键数据。把“不是 root”当作安全结论，会遗漏补充组、目录权限和服务凭据带来的访问能力。

文件侧可以执行 stat -c '%A %U %G %n' /etc/demo/app.conf，并沿路径检查父目录权限。文件本身不可写，不代表路径上的父目录允许被随意改动时仍然可靠。反过来，文件可读也不代表账号一定能穿过所有父目录。这里沿用 uid、gid、rwx 的基础知识，不需要先掌握内核实现，就能描述进程对资产的实际能力。

最终形成简短的威胁记录：“应用进程可能因输入处理缺陷失守；攻击者能使用应用账号和现有数据库凭据；应阻止其进入管理区、读取备份和修改安全配置。”再为每项假设注明证据、负责人和复查时间。模型不追求列出所有攻击名称，而要让允许流、账号权限和检测规则有明确理由。

3 防火墙、分段与最小权限

防火墙依据来源、目的、协议、端口及连接状态等条件决定是否放行。入口规则常写为“允许指定来源访问目的 TCP 端口”，但完整通信还包含回程。具备连接状态跟踪的防火墙通常可以允许已建立连接的返回流量；无状态访问控制需要单独考虑方向与返回端口。不能把某个平台的默认行为当成所有设备共有的保证。

默认拒绝的意思是：没有明确允许理由的通信被拒绝。它需要配套允许清单，否则 DNS、时间同步、软件更新等依赖可能一起中断。最小权限则要求把允许范围缩到任务所需，包括来源范围、目的资源、操作权限和生效时间。0.0.0.0/0 到数据库端口很容易配置，却把“应用需要访问数据库”扩大成了“任意来源都可尝试连接”。

网络分段把不同信任条件的设备放进不同区域，并让跨区路径经过可执行策略的控制点。例如入口区是 10.38.10.0/24，服务区是 10.38.20.0/24，数据区是 10.38.30.0/24，管理区是 10.38.40.0/24。这些地址只是标签；是否真正隔离，要看路由、交换配置和过滤位置。仅修改子网名称或画出不同颜色的方框，不会自动产生访问限制。

分段、过滤与身份验证各有作用。分段让通信经过可控路径，过滤缩小可达范围，服务身份验证决定连接建立后能做什么。主机上的最小权限继续限制进程：应用使用独立账号，数据库账号只获得必要库表权限，配置由管理员写入，备份由独立任务保存。网络允许某个端口，不意味着该连接里的每项操作都已获授权。

对 SSH 管理入口，可以允许管理跳板访问目标的 TCP 22，同时要求使用个人账号并保留登录记录。这样既限制网络路径，又能追溯操作主体。共享管理员账号会让审计难以区分人员；把管理端口换成其他数字只能减少部分扫描噪声，不能替代来源限制与身份验证。配置安全控制时，要写清它具体阻止什么，而不是把任何变化都称作加固。

修改远程主机的过滤规则还要保护运维通路。先确认控制台或备用入口可用，保存现有规则，安排回滚，再在维护窗口应用变更。已有 SSH 会话仍然存活，可能只是被“已建立连接”规则放行，不能证明新登录也能成功。验证必须包含新建管理连接，否则下一次断线就可能把自己挡在外面。

4 动手：画一张分区与允许流表

先在纸上或文本中画出前述 4 个区，给实际主机分配地址：入口网关 10.38.10.10、应用 10.38.20.20、数据库 10.38.30.30、管理跳板 10.38.40.10。再标出过滤控制点和日志去向。画图时必须注明跨区通信实际经过哪里，并检查是否存在绕行接口，例如应用主机同时连接管理网络，或备份共享直接暴露给整个服务区。

允许流表记录连接的发起方向。以下端口只是本课环境的约定，落地时要替换为实际监听端口。每条规则还应补充负责人、用途和复查日期；临时规则需要到期时间。表中未列出的新连接默认拒绝，返回流量按经过核实的状态规则处理。

这张表还不是完整生产策略。日志发送、备份拉取和软件更新必须根据实际方案补充，不能因为表里没有就临时放开整个网段。以更新为例，可以通过受控出口访问获准仓库，并记录变更；不能为了安装软件永久允许任意目的地址和端口。先解释依赖，再增加规则，能避免允许清单逐渐退化成全通清单。

接下来检查观察到的网络事实。ip -br addr 查看接口地址，ip route 查看路由，ip route get 10.38.30.30 查看本机到数据库地址选用的路径；它不证明中间设备放行。ss -lnt 查看目的主机是否监听。若使用 nftables，管理员可执行 sudo nft list ruleset 阅读当前规则，但要同时核对网络侧过滤；本课不直接给出覆盖现有规则的写入命令。

验证要从规则指定的来源发起。服务区可以用 nc -vz -w 3 10.38.30.30 5432 检查 TCP 连接，前提是练习机已安装该工具。从未经允许的入口主机再做相同检查，应连接失败。成功只证明端口可连接，数据库授权还要另测；失败也不能直接证明防火墙有效，因为目的进程可能根本没有启动。正向成功与反向受阻应共同构成证据。

对应用入口，可使用 curl --connect-timeout 3 --max-time 5 https://panel.example.test/health，并为练习域名准备正确解析和可信证书。不要为了消除报错而长期跳过证书验证。验收记录写明时间、发起主机、账号、目标、预期、实际结果与相关日志。最后从管理跳板新建 SSH 会话，确认变更没有破坏管理通路，再结束维护。

5 检测、响应与纵深防御取舍

预防控制总有覆盖边界，因此还需要检测与响应。检测首先建立正常行为的参照：应用通常连接哪些地址、谁在什么时间登录、配置通常由谁修改。初学阶段不必收集所有数据，可以先关注跨区拒绝、异常登录、关键文件修改、服务重启和监听端口变化。每种记录都应回答明确问题，避免只有大量日志却无人知道如何使用。

主机上可以用 journalctl -u demo.service --since '10 minutes ago' 查看示例服务最近的记录，实际单元名称应按环境替换。ss -nt 显示当前 TCP 连接，重复采样能帮助发现新的目的地址，但短暂连接可能被漏掉。过滤设备的计数器和日志能补充路径证据。需要确认每种来源的时间、时区和记录范围，否则几条本不相关的事件可能被错误拼接。

一条拒绝日志并不等于入侵成功，也不必立即全网隔离。先核对来源是否为批准的扫描或刚上线的服务，再观察是否出现连续跨区尝试、异常账号登录或关键文件改动。告警应尽量提供来源、目的、时间、命中规则与关联主机，让值班人员能开始验证。只有“发现可疑活动”而没有定位信息，会延长响应时间。

若确认应用主机被控制，先限制其跨区与外联能力，同时保留授权的调查通路。按流程保存相关日志、连接信息和配置状态，再处理凭据与恢复。不要为了尽快“恢复正常”立即清空日志或反复重启。凭据更换应在可信环境进行，并撤销旧凭据；若主机仍受控制，在该主机直接写入新凭据可能再次泄露。恢复后还要验证初始入口已修复。

纵深防御也有成本。分区越细，策略数量、变更协调和排障工作通常越多；日志越详细，存储、隐私保护和筛选成本越高。目标是让高价值资产获得与风险相称的保护，同时让团队能持续维护。没有负责人和更新流程的精细规则，可能在紧急故障时被整批放开，长期效果反而下降。

可以先把管理区和备份从普通服务区隔开，再按实际依赖逐步细分。每增加一个控制，都说明减少了什么风险、增加了哪些维护任务、怎样判断失效。允许例外时记录责任人与期限。这里的取舍需要结合业务可用性、团队能力和恢复目标，不存在适用于所有环境的唯一分区数量或日志保留天数。

6 常见坑：把边界防火墙当唯一控制点

边界防火墙主要约束经过边界的通信。应用主机之间的直接访问、同一二层网络内的通信、主机本地文件操作，可能都不经过它。如果攻击者通过合法开放的 HTTPS 服务获得进程执行能力，公网入口规则仍然可能全部符合设计。此时真正决定损失范围的是内部路径、账号权限、服务授权和恢复措施。

同一个二层网络中的主机通常可以直接交换数据，流量不一定经过跨区路由设备。把 2 台主机写进不同资产分组，不代表它们之间有隔离。即使配置了不同 VLAN，也要确认跨 VLAN 路径受控，没有被其他路由、双网卡主机或错误交换配置绕开。分区的有效性必须通过真实来源的连接测试和设备配置共同验证。

另一个坑是把网络位置当身份。来自服务区的连接，只能说明它经过某条网络路径；该主机可能已失守，账号也可能被盗用。数据库需要自己的身份验证和操作授权，管理接口需要独立限制，配置与备份需要文件权限保护。内部通信若涉及敏感内容，还应考虑传输保护，具体密码学机制留到 S39。

排障时也容易误判。连接超时可能来自丢弃规则、路由问题、返回路径故障或目标无响应；连接被拒绝常见于没有监听，也可能是设备主动拒绝。看到超时就增加放行规则，可能既没有修复故障，又扩大攻击面。应先核对地址与解析，再查路由、监听、过滤和服务日志，逐步缩小范围。

ping 成功只表示某种 ICMP 通信得到响应，不能证明 TCP 5432 可达；ping 失败也不证明 HTTPS 不可用。端口连通后出现认证失败，排查重点应转向账号和服务授权。将失败所在阶段记清楚，才能把变更限制在相关控制点，避免遇到任何问题都临时关闭防火墙。

还有一个运维陷阱是把“规则已下发”当成“风险已消除”。规则可能应用到错误接口，目标地址可能变化，旧连接可能继续存在，IPv6 也可能未被同等约束。基线验收应覆盖实际启用的地址族、接口与连接状态。没有启用的功能无需凭空增加复杂度，但已经存在的路径不能因检查表只写 IPv4 而被忽略。

7 案例：横向移动穿过平坦二层

某内部监测环境最初只有入口防火墙。应用、文件共享、数据库和管理主机都接在同一个二层网络，入口只开放 TCP 443，管理员因此认为内部已经安全。应用进程使用普通账号，但配置中保存了数据库凭据；备份共享为了方便排障，也允许整个内部网访问。这些条件把入口风险与内部资源连在了一起。

一次应用缺陷使攻击者能够以应用账号执行命令。攻击者先查看本机连接与配置，得到数据库地址和共享路径，再尝试访问其他主机。由于这些通信在本地二层网络中直接完成，没有经过入口防火墙，公网规则没有产生对应拒绝记录。部分目标服务还把整个内部网列为可信来源，扩大了后续操作空间。

值班人员最先看到数据库认证失败增加，随后发现应用主机向多个内部地址建立连接。单独看认证失败，也可能是应用配置错误；结合连接来源、变化时间和配置文件访问线索，才形成更可信的判断。调查应区分已确认的访问和仅被尝试的访问，不应把每个目标都写成已经失陷，也不能因没有入口告警就排除事件。

响应人员先在主机或接入侧限制应用主机的内部通信，因为入口设备无法控制这条本地路径。随后保存日志与必要现场信息，撤销应用相关凭据，检查数据库操作和备份访问记录。若日志缺失，应明确写出调查盲区。缺少记录不能证明数据未被读取；恢复方案需要结合可能暴露的资产，决定凭据轮换与数据完整性检查范围。

整改把管理、数据和备份路径从普通服务通信中分开。应用只被允许连接指定数据库端口，数据库账号仅具备所需权限，备份由受控任务访问，管理登录来自跳板。应用配置由管理员维护，服务账号无权修改安全规则。这样，即使同类应用缺陷再次出现，攻击者能触及的资源与操作也会受到更多限制。

这个案例的关键并非要求部署最多设备，而是让控制点位于真实流量路径上，并为每次越权尝试留下可用证据。复盘时应分别回答入口为何失守、内部为何可达、权限为何过大、告警为何较晚。每个问题对应不同整改负责人，才能避免只修补应用漏洞，却保留相同的横向移动条件。

8 把安全控制写进网络基线

网络基线是可重复检查的约定。它应记录分区、接口、地址范围、允许流、管理入口、账号要求、日志去向、备份恢复方式和例外流程。描述要能被验证，例如“数据库只接受指定应用地址发起的 TCP 5432 连接，其他测试来源被阻止”，比“数据库处于安全内网”更有执行价值。

把基线与资产清单关联起来：每台主机有哪些接口、运行哪些服务、由谁负责、使用哪些服务账号、关键配置放在哪里。新增监听端口、网卡、共享目录或服务依赖都应触发复查。主机镜像符合基线，并不保证部署后持续符合；一次临时排障留下的宽泛规则，就可能改变原先的隔离边界。

规则变更需要保存旧配置、变更原因、审批或授权记录、测试结果和回滚条件。先检验规则语法与依赖，再按可控范围应用，验证正向业务与反向限制。紧急例外仍然需要期限和负责人。到期复查时，确认例外已撤销或已有充分理由转为正式规则，避免只在工单里写“临时”，配置却长期存在。

检测基线也要可执行。定义关键日志来源与接收位置，检查时钟同步和日志是否持续到达，限制日志访问并保护留存。针对“应用尝试进入管理区”“新出现的远程监听”“关键配置被异常账号修改”等场景，安排获准的模拟验证。验收要看值班人员是否收到足够信息并能采取措施，不能只确认日志目录里有文件。

最后安排恢复演练。备份任务成功的退出码不等于备份可恢复，需要在隔离环境实际还原并检查关键数据与权限。安全基线应写明谁可以发起隔离、谁决定恢复、如何联系业务负责人，以及恢复后怎样验证服务和安全控制。可用性与安全控制放在同一份操作约定中，故障时才不必靠临时猜测取舍。

9 从网络安全走向密码学应用（S39）

网络控制解决“哪些路径可以通信”，但通信路径被允许之后，仍要解决内容是否被旁观、对端身份是否可靠、数据是否被改动。例如应用连接到了允许的数据库地址，不能仅凭地址判断对端一定是真实服务。名称解析错误、网络配置变化或凭据泄露，都可能让“路径正确”与“信任正确”出现差距。

S39 将从应用角度说明加密、摘要、身份认证和证书。此处先建立边界：加密用于保护内容，摘要用于支持完整性检查，带有密钥或签名的机制才能在相应条件下提供来源真实性。把文件和旁边的摘要同时放在可被任意修改的位置，不能仅靠两者匹配证明文件可信，因为攻击者可能同时替换它们。

HTTPS 把传输保护与服务身份验证结合起来，但仍依赖正确验证和凭据管理。命令报证书错误时，应检查名称、有效期、信任配置与系统时间；跳过验证会改变原先的信任条件。与此同时，即使传输受到保护，已被控制的应用进程仍可能读取它有权读取的明文文件。密码学控制需要与账号权限和进程隔离共同使用。

进入下一课前，可以用本课的环境提出具体问题：管理员如何确认连接的是正确跳板，应用如何验证数据库服务，备份如何发现被篡改，密钥由谁保存、轮换与撤销。先把主体、资产和路径说清楚，再选择机制，能避免把“已经加密”误当作所有风险的统一答案。

放进方案里

为内部监测服务编写方案时，先声明保护对象：应用配置、数据库、管理员凭据、备份和服务可用性。威胁假设包含公网入口受到攻击，以及应用进程失守后尝试访问内部资源。方案的目标是限制越权路径，及时发现异常，并使团队能够在保留调查依据后恢复服务。

部署图标出入口区、服务区、数据区、管理区及实际过滤位置。允许流表逐条写出发起方、接收方、协议、目的端口、用途、负责人和复查日期；未列出的新连接默认拒绝。解析、时间同步、更新、日志与备份依赖分别补齐。应用使用专用账号，配置由管理员写入，数据库授权限定所需操作，备份不向普通服务账号开放。

上线前从指定来源验证业务访问，再从未经允许的来源验证限制，同时检查目的监听和过滤日志，排除“服务没启动所以测试失败”的假象。另从管理跳板新建登录，验证远程运维可用。记录测试时间、主机、预期与结果，保存旧配置并明确回滚条件。涉及地址族或多接口时，验收覆盖实际存在的全部路径。

权限验收另用应用账号尝试读取备份、修改配置和执行超出授权的数据库操作，均应被拒绝；正常查询仍须成功。保存账号所属组、文件权限与数据库授权快照，关联测试记录。测试仅使用隔离样本和获准账号，不以删除生产数据验证写入限制。

运行阶段关注跨区拒绝、异常登录、监听变化和关键配置修改，确认日志持续送达且时间可对齐。应急流程指定隔离权限、证据保存位置、凭据撤销与恢复负责人；备份通过隔离还原验证。临时放行设定期限，到期撤销或正式复审。对可用性影响较大的控制分步实施，每步都保留验证结果，使分区设计、运行配置与值班操作保持一致。

10 小结：下一步密码学应用（S39）

网络安全基础是把资产、路径、权限、观测和恢复连起来：先说明保护什么，再限制可达范围与操作能力，用证据检查控制是否生效，并为失守保留收敛办法。边界防火墙只是其中的控制点，真实路径上的分段、主机权限和服务授权决定内部损失范围。

自测时尝试解释：为什么端口连通不能证明操作已获授权？为什么同一二层网络里的访问可能绕过边界？怎样用正向成功与反向受阻验证允许流表？如果应用账号已经失守，哪些控制还应继续有效？能结合命令、日志和配置回答这些问题，就具备了进入 S39 的基础。下一课继续处理被允许的通信如何保护内容、验证身份与检查完整性。