运维常见题-网络安全

🤔 网络攻击有哪些常见类型及特点？

• 网络攻击按目标层可分为：①网络层 DDoS（拒绝服务）②传输/应用层漏洞利用（SQL 注入、XSS、CSRF）③身份与密码攻击（暴力破解、撞库）④社会工程（钓鱼）⑤中间人/劫持（ARP 欺骗、DNS 劫持）⑥供应链与新型攻击（勒索软件、APT）。核心认识：攻击面从"打网络"到"骗人"到"利用漏洞"全覆盖，防御需纵深。

  • 拒绝服务类（DDoS/DoS）

    • DDoS（分布式拒绝服务）：攻击者控制大量傀儡机（僵尸网络）或利用反射放大（DNS/NTP/SSDP amplification），向目标发起海量请求，耗尽带宽/连接/资源，使服务不可用
    • CC 攻击：DDoS 的应用层变种，发起大量看似合法的 HTTP 请求（如高频请求动态页面），耗尽应用/数据库资源，比纯流量型更难防御
    • 特点：难以定位单点，防护需流量清洗、限流、WAF

  • Web 应用漏洞利用类

    • SQL 注入：在输入框/URL 参数拼接恶意 SQL 语句，窃取/篡改数据库数据。防御：参数化查询、输入校验、最小权限
    • XSS（跨站脚本）：向页面注入恶意脚本，窃取用户 Cookie/会话、钓鱼。防御：输出编码、CSP、HttpOnly Cookie
    • CSRF（跨站请求伪造）：诱导已登录用户在不知情下发起操作（转账、改密）。防御：CSRF Token、SameSite Cookie、验证码
    • SSRF（服务端请求伪造）：利用服务端发起任意请求，访问内网/元数据。防御：URL 白名单、限制内网访问、禁用协议
    • 文件上传漏洞：上传恶意文件（WebShell）控制服务器。防御：白名单校验类型、重命名、隔离目录
    • 特点：直接攻击应用逻辑和数据，危害大，需代码审计 + WAF + 安全开发流程

  • 身份与密码攻击类

    • 暴力破解：用字典/穷举猜测密码（SSH/RDP/后台）。防御：锁定策略、验证码、密钥认证
    • 撞库：用其他平台泄露的账号密码尝试登录。防御：强制强密码、多因素认证（MFA）、泄露检测
    • 密码喷洒：用少量常见密码试大量账号（规避锁定）。防御：监控登录失败、异常登录告警
    • 钓鱼：伪造邮件/网站骗取账号密码。防御：安全意识培训、邮件网关、URL 检测

  • 中间人/劫持类

    • ARP 欺骗：伪造 ARP 应答，截获同网段流量（中间人）。防御：DHCP Snooping、DAI、静态 ARP
    • DNS 劫持/污染：篡改 DNS 解析，指向恶意站点。防御：DNSSEC、DoH/DoT、安全 DNS
    • 中间人攻击（MITM）：截获并篡改明文通信。防御：HTTPS/TLS、证书校验
    • 会话劫持：窃取 Session/Cookie 冒充用户。防御：HttpOnly、Secure、会话过期

  • 恶意代码与供应链类

    • 勒索软件（Ransomware）：加密数据索要赎金。防御：备份、隔离、邮件防护、补丁
    • APT（高级持续性威胁）：长期潜伏的定向攻击（鱼叉、0day）。防御：纵深防御、流量审计、威胁情报
    • 供应链攻击：攻击软件依赖/更新链（如 SolarWinds）；Log4j/Log4Shell 属广泛依赖的组件漏洞（性质不同，但影响面同样巨大）。防御：依赖审计（SCA）、SBOM、镜像扫描
    • 后门/WebShell：预留或上传后门，长期控制服务器。防御：文件完整性监控（FIM）、日志审计

• 协助记忆

  • 分类口诀：“打资源（DDoS/CC）、打应用（注入/XSS）、打密码（爆破/撞库）、骗人（钓鱼）、劫持（ARP/DNS）、放病毒（勒索/APT）"。
  • 防御总纲：“纵深防御——边界（防火墙）+ 应用（WAF）+ 主机（加固/EDR）+ 人（意识）+ 数据（备份）"。

• 进阶思考

  • DDoS 和 CC 攻击的本质区别是什么？
    • DDoS 是网络/传输层流量型（耗尽带宽、连接表），CC 是应用层请求型（耗尽应用资源）。CC 攻击包量小、难从流量区分，需结合行为分析（请求频率、UA、IP 分布）识别。
  • 为什么说"攻击面从技术扩展到人”？
    • 技术防线（防火墙/补丁）越来越强，攻击者转向"人是最大弱点”：钓鱼邮件、社工骗取凭证。所以安全不仅是技术，更是管理 + 意识培训。
  • 0day 漏洞为什么可怕？如何应对？
    • 0day 是未公开、无补丁的漏洞，防无可防。应对：纵深防御（即使单层被攻破，其他层仍拦截）、威胁情报（发现即响应）、EDR 行为检测（不依赖特征库）、网络隔离（限制横向移动）。

• 扩展信息

  • 常见攻击分类框架：
    • STRIDE：Spoofing（伪装）、Tampering（篡改）、Repudiation（抵赖）、Information Disclosure（泄露）、Denial of Service（拒绝服务）、Elevation of Privilege（提权）
    • MITRE ATT&CK：攻击行为知识库，按**战术列（Tactics）**组织（含侦察 Reconnaissance、初始访问、执行、持久化、提权、防御规避、凭据访问、发现、横向移动、收集、命令控制、渗出 Exfiltration、影响等），而非线性"杀伤链"（那是 Lockheed Martin 的概念），是威胁建模和检测的核心框架
  • 一句话记住攻击面：“网络（DDoS）+ 系统（漏洞）+ 应用（注入）+ 数据（泄露）+ 人（钓鱼）”

🤔 如果 Linux 服务器被入侵，会有哪些现象？

• Linux 被入侵的常见现象分七类：①账号异常（新增用户/免密登录）②进程异常（陌生进程/高 CPU）③网络异常（外连/开放端口）④文件异常（新增后门/权限改动/文件被加密）⑤日志异常（登录记录被删/大量失败登录）⑥系统行为异常（反弹 Shell/定时任务）⑦性能异常（CPU/带宽异常占用）。核心警觉：“没配置过的东西出现"就是最大嫌疑。

  • 账号与权限异常

    • 新增陌生用户（/etc/passwd 多了 uid=0 的用户）：awk -F: '$3==0' /etc/passwd 查 UID 0 账号
    • 免密登录：~/.ssh/authorized_keys 多了陌生公钥
    • 用户被加入 sudoers 组（提权后门）
    • 账号密码被改（如 root 无法登录，或密码被改）

  • 进程与命令异常

    • 陌生进程占用高 CPU/内存（挖矿木马常表现为 CPU 飙高）
    • 恶意进程伪装成系统进程名（如 kthreadd 这类内核线程名通常带方括号 [kthreadd]，若出现不带方括号的同名进程才可疑）
    • 命令被替换/篡改（ls、ps 等被植入后门，stat /bin/ls 看 mtime）
    • 出现反弹 Shell 进程（bash -i、nc -e（仅部分 netcat 实现支持）、/dev/tcp 反弹、python 反弹）

  • 网络异常

    • 陌生 IP 的对外连接（挖矿/数据外传）：ss -antp 查外连
    • 开放了未配置的端口（后门监听）：ss -lnp
    • 连接高频率心跳（C2 通信特征）
    • 网络流量异常增长（外传数据）

  • 文件异常

    • 新增可疑文件（如 /tmp/、/dev/shm/ 下的陌生可执行文件）
    • 文件被篡改/权限异常（chmod 777 的敏感文件）
    • 文件被加密（勒索软件特征：.encrypted 后缀）
    • 新增 WebShell（网站目录下 .php/.jsp 后门文件）
    • 文件 mtime 异常（可疑时间点被修改）

  • 日志异常

    • 登录日志被清空/篡改（/var/log/wtmp、lastlog 异常）——攻击者抹痕
    • 大量失败登录记录（暴力破解）
    • SSH 登录记录中出现陌生 IP/陌生时间段
    • 定时任务（crontab）里多了陌生条目（持久化）

  • 系统行为异常

    • /etc/crontab、cron.d 被植入恶意定时任务
    • systemd 服务里多了陌生服务（systemctl list-units）
    • 启动项被修改（/etc/rc.local、/etc/init.d/）
    • 内核模块被加载恶意 LKM（lsmod）
    • 反弹 Shell 迹象（bash 子进程连外）

  • 性能与资源异常

    • CPU/内存长时间高占用（挖矿特征）
    • 磁盘被占满（异常日志/数据写入）
    • 带宽异常占用（外传数据）
    • 系统频繁重启（被改关键文件导致崩溃）

• 协助记忆

  • 现象排查口诀：“账号多了、进程怪了、端口开了、文件变了、日志没了、定时任务加了、CPU 飙了——都是入侵嫌疑”。
  • 核心警惕：“一切没配置过的东西出现，先当入侵处理”。

• 进阶思考

  • 为什么攻击者要"抹日志”？怎么发现被抹日志？
    • 抹日志是为了隐藏入侵痕迹、延缓发现。发现方法：①日志文件时间戳异常（mtime 被改）②日志空洞（时间不连续）③history 被清空但 shell 历史文件还在 ④系统日志与审计日志（/var/log/audit/）不一致。所以生产环境应日志异地同步/集中收集（即使本地被删，远端还有）。
  • 挖矿木马的典型特征是什么？
    • CPU 长时间 100%（被挖矿进程占用）、进程名伪装（kdevtmpfsi、xmrig 等）、连接境外矿池（常见 3333/14444 等端口）、定时任务持久化、常驻 /tmp//dev/shm。发现后先断网隔离、再排查持久化、清除进程和文件。
  • 入侵后第一反应应该是什么？
    • ①立即断网/隔离（防止横向扩散和数据外传）②保留现场（内存快照、日志备份，不要急着重启）③排查入侵途径和持久化后门 ④评估损失（数据泄露范围）⑤按应急预案上报。切记：先保全证据，再恢复系统。

• 扩展信息

  • 应急响应常用命令速查：
    1 2 3 4 5 6 7 8 9 10

    w / who -a # 当前登录用户 last -a # 最近登录记录 awk -F: '$3==0' /etc/passwd # UID 0 账号 cat ~/.ssh/authorized_keys # SSH 授权密钥 ss -antp # 所有连接+进程 ss -lnp # 监听端口 ps -ef / ps aux # 进程 crontab -l # 定时任务 ls -lt /tmp /dev/shm # 可疑目录文件 find / -mtime -3 -type f 2>/dev/null | head # 近3天修改文件

  • 主机入侵检测思路：
    • 文件完整性（AIDE/Tripwire 基线比对）、进程监控（EDR）、日志集中分析（ELK/SIEM）、异常行为告警（Fail2ban、审计）

🤔 怀疑某台 Linux 服务器被入侵，如何排查？

• 入侵排查遵循"证据保全 → 系统采集 → 分析定位 → 清除与恢复"的应急响应流程。核心：先断网隔离、保证据，再用系统命令全面采集异常点（账号/进程/网络/文件/日志/定时任务），最后分析入侵途径并清除后门。

  • 第一步：隔离与保全证据

    • 断网/隔离：拔出网线或 iptables 封锁（防止横向扩散、数据外传）——但先保留内存/日志证据再断
    • 备份证据：/var/log、/etc/passwd、/etc/shadow、SSH 配置、bash 历史、进程快照
    • 内存取证（如有能力）：lime 抓内存镜像（高级，事后分析）
    • ⚠️ 不要急着重启/杀进程——可能丢失内存证据、触发攻击者销毁

  • 第二步：采集系统状态

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

    # 账号层 awk -F: '$3==0{print}' /etc/passwd # UID 0 账号（提权后门） cat /etc/shadow | awk -F: '$2!="!"&&$2!="*"{print}' # 有密码的账号 ls -la /home/*/.ssh/authorized_keys # SSH 密钥 who / w / last # 登录记录 # 进程层 ps -ef --sort=-%cpu | head # CPU 排序找可疑进程 ls -l /proc/<PID>/exe # 看进程真实二进制 cat /proc/<PID>/cmdline | tr '\0' ' ' # 看进程启动参数（NUL 分隔，转成空格可读） # 网络层 ss -antp # 连接+进程 ss -lnp # 监听端口 netstat -antp # 网络连接（含 LISTEN，外连需过滤 ESTABLISHED） # 定时任务/服务 crontab -l; cat /etc/crontab; ls /etc/cron.*/ systemctl list-unit-files | grep enabled ls -la /etc/rc.local /etc/init.d/ # 文件层 find /tmp /dev/shm /var/tmp -type f -executable 2>/dev/null find / -name '*.ko' 2>/dev/null | xargs ls -lt # 内核模块（可疑 LKM） cat /etc/ld.so.preload 2>/dev/null # LD_PRELOAD 后门（最经典持久化点） echo $LD_PRELOAD # 环境变量级 preload stat /bin/ls /bin/ps /usr/bin/top # 检查命令是否被替换 ls -lt /var/log/ # 日志时间戳异常 find / -path /proc -prune -o -path /sys -prune -o -path /dev -prune -o -mtime -3 -type f -print 2>/dev/null | grep -v -E 'var/log' # 近期改动（跳过伪文件系统）

  • 第三步：分析定位

    • 从异常进程的 /proc/<PID>/exe 和 cmdline 判断恶意程序
    • 从 ss -antp 的外连 IP 反查（威胁情报库查 C2）
    • 分析登录日志：last -f /var/log/btmp | tail（失败登录）、grep sshd /var/log/secure
    • 检查历史命令：cat ~/.bash_history（但被入侵后可能被清）
    • 用 lsof +L1 查已被删除但仍运行的文件（木马常见手法）

  • 第四步：清除与恢复

    • 杀掉恶意进程、删除恶意文件/账号/定时任务
    • 清理 SSH 后门（删除陌生 authorized_keys、恢复 sshd_config）
    • 修改所有账号密码、撤销可疑密钥
    • 打补丁：修复入侵途径（漏洞、弱口令）
    • ⚠️ 入侵后建议重装系统或至少全面恢复：被 rootkit 攻破的系统难以彻底清除（内核级后门）

  • 第五步：复盘加固

    • 分析入侵途径（弱口令？漏洞？钓鱼？）
    • 修复漏洞、加固安全基线、启用日志集中监控
    • 更新应急预案，纳入安全事件库

• 协助记忆

  • 排查五步：“隔离（断网）→ 采集（账号/进程/网络/文件/日志）→ 定位（找后门）→ 清除（杀进程删文件）→ 复盘（补漏洞）"。
  • 采集口诀：“账号查 UID0，进程看 /proc，网络看 ss，文件看 /tmp，日志看 btmp”。

• 进阶思考

  • 为什么说被 rootkit 入侵后"重装比清杀更可靠”？
    • rootkit 可隐藏进程/文件/网络连接，甚至篡改内核（LKM rootkit），常规命令看到的都是"假象"。即使杀了可见后门，内核级后门可能仍在。所以关键业务主机被 rootkit 入侵，重装系统/从干净镜像恢复是标准做法。
  • 如何判断命令是否被替换（被 Rootkit）？
    • 用静态编译的干净工具（如 busybox、挂载只读的干净系统）对比：/bin/ls 的 mtime、hash（sha256sum）与官方 RPM（rpm -V 校验）对比。被替换的命令（ps/netstat/ls）会"选择性失明"。
  • 入侵排查中"保证据"为什么重要？
    • 证据用于：①判断攻击来源和手法（反制/溯源）②法律追责（公安网安取证）③复盘防再次入侵。若急着重启/重装，内存中的攻击进程、网络连接证据全丢，无法溯源。

• 扩展信息

  • 入侵排查工具包：
    • chkrootkit/rkhunter：rootkit 扫描
    • clamav：病毒扫描
    • aide/tripwire：文件完整性基线
    • fail2ban：暴力破解防御
    • sysdig/auditd：系统调用审计
    • osquery：主机活动查询（EDR 基石）
  • 应急响应框架参考：
    • 六阶段（国内通行拆分，官方 NIST 800-61 为四阶段：准备→检测分析→遏制/根除/恢复→事后）：准备 → 检测分析 → 遏制 → 根除 → 恢复 → 事后
    • 实战口诀：“先隔离、再取证、后清除、终加固”

🤔 如何加强 Linux 服务器的安全性？

• Linux 安全加固核心是"纵深防御 + 最小权限"：系统层面（补丁/账号/SSH/权限/文件系统）、网络层面（防火墙/服务最小化）、应用层面（Web/数据库加固）、监控层面（日志/告警/入侵检测）四层协同。

  • 系统层面

    • 及时打补丁：yum update/apt upgrade（漏洞修复第一优先级）
    • 账号安全：禁用 root 远程登录（PermitRootLogin no）、强密码策略（/etc/login.defs）、最小化账号、定期清理僵尸账号
    • 密码策略：密码复杂度（pam_pwquality/pwquality.conf）+ 有效期（chage）、登录失败锁定（faillock，pam_tally2 在 RHEL 8 已弃用/9 移除）
    • 权限最小化：chmod 收紧敏感文件（/etc/shadow 600）、umask 027、sudo 白名单

  • SSH 加固

    • 禁用密码登录，改用密钥认证（PasswordAuthentication no）
    • 修改默认端口（可选，非关键）
    • 限制登录用户/IP（AllowUsers/AllowGroups）
    • 登录失败锁定（fail2ban）
    • 禁用 root 登录、限制转发（AllowTcpForwarding）

  • 网络层面

    • 防火墙：firewalld/iptables 默认拒绝，只放行必要端口
    • 最小化服务：只跑必要服务，关闭不需要的服务（systemctl disable）
    • 禁用不需要的网络协议：ICMP 重定向、IP 转发（除非必要）
    • 关闭 rsh/telnet 等明文协议，用 SSH

  • 文件系统层面

    • 关键目录只读挂载（/usr、/boot 可只读）
    • /tmp 独立分区（noexec 防执行木马）
    • 禁用 USB 存储（modprobe -r usb_storage、blacklist）
    • SELinux/AppArmor 开启（强制访问控制）
    • 文件完整性监控（AIDE 基线）

  • 应用层面

    • Web：WAF、隐藏版本号、禁用目录列表、参数校验
    • 数据库：最小权限、网络隔离（不对外）、强密码
    • 中间件：升级、去默认配置、最小化模块

  • 监控与日志层面

    • 日志集中收集（rsyslog 远程/ELK）
    • 入侵检测（IDS/EDR/主机审计）
    • 安全监控告警（异常登录、外连、文件变更）
    • 定期安全扫描（漏洞扫描、基线核查）

• 协助记忆

  • 加固口诀：“打补丁、锁账号、堵端口、收权限、开监控”。
  • 纵深防御：“边界（防火墙）→ 主机（加固）→ 应用（加固）→ 数据（备份加密）→ 人（意识）"。

• 进阶思考

  • 为什么 SELinux 常被关闭？该不该开？
    • SELinux 的强制访问控制（MAC）能防提权/越权（即使进程被攻破也被限制），但配置复杂、易踩坑（服务被拒绝），运维常图省事关闭。最佳实践：开启 SELinux，用 ausearch/sealert 排查告警，而不是直接关闭。
  • “最小权限原则"在 Linux 上如何落地？
    • ①服务账号最小化：每个服务独立账号，不给 root；②sudo 最小化：只给需要的命令；③文件权限最小化：默认 644/755，敏感文件更严；④数据库/Web 最小权限：应用账号只读/只操作业务库。
  • 安全加固和业务可用性如何平衡？
    • 加固不能影响业务：先评估加固项对业务的影响（如 SELinux、防火墙改动），在测试环境验证后灰度上线；关键业务用"最小影响加固”（先做无侵入的：补丁、密码策略、日志），再逐步深入。

• 扩展信息

  • 常用加固基线参考：
    • CIS Benchmarks（最权威的配置基线）
    • 等保 2.0（国内合规要求）
    • 各厂商安全加固手册（如红帽安全指南）
  • 一键加固脚本思路：
    • SSH 加固 → 防火墙规则 → 密码策略 → 关闭多余服务 → 日志配置 → 权限收紧 → 打补丁
    • 工具：lynis（安全审计工具）、CIS 自动加固脚本、Ansible 加固 playbook

🤔 如果某个软件被爆存在高危漏洞，你会怎么处置？

• 高危漏洞处置遵循"评估→遏制→修复→验证→复盘"闭环，核心是先评估影响面与风险再动手，能修先修、不能修先缓解：评估影响范围 → 判断能否立即修复 → 可修则打补丁/升级，不可修则临时缓解（WAF/禁用功能/隔离）+ 持续监控。

  • 第一步：评估影响

    • 影响范围：哪些服务器/应用使用该软件？是否暴露在公网？
    • 可利用性：漏洞是否已被公开利用（PoC/在野利用）？利用难度？
    • 风险评估：资产价值 × 漏洞严重性 × 暴露程度，确定处置优先级
    • 参考 CVE/CNVD/厂商公告、威胁情报（是否已出现在野攻击）

  • 第二步：遏制（先止血）

    • 暴露面收敛：公网入口加 WAF 规则、限制来源 IP、关闭不必要的端口
    • 临时禁用受影响功能/模块（如能用配置文件关闭）
    • 隔离：受影响系统网络隔离（如移出公网/内网分段）
    • 会话/凭据轮换：如果可能泄露凭据，重置相关账号密码

  • 第三步：修复（根除）

    • 打补丁/升级到修复版本（优先：官方补丁）
    • 若官方补丁未出：临时缓解措施（配置变通、开源补丁、社区 workaround）
    • 修复后验证：功能回归测试 + 漏洞复测（扫描确认已修复）

  • 第四步：复盘与预防

    • 排查是否已被利用（日志、IOC 检查）
    • 纳入漏洞管理流程（定期扫描、补丁管理）
    • 建立漏洞应急响应预案（含演练）

  • 处置优先级决策

    1 2 3

    受影响且可修 → 立即打补丁 受影响但不可立即修 → 临时缓解 + 监控 + 排期修复 未受影响 → 观察 + 预防性评估

• 协助记忆

  • 处置闭环：“评估（影响面）→ 遏制（止血）→ 修复（补丁）→ 验证（复测）→ 复盘（防再发）"。
  • 优先级口诀：“公网优先、被利用优先、能修先修、不能修先挡”。

• 进阶思考

  • 什么时候用"临时缓解"而不是"立即升级”？
    • 当①升级会导致服务中断/兼容性问题；②官方补丁未发布；③升级成本高于缓解成本时。此时用 WAF 规则、禁用功能、网络隔离等缓解手段，同时密切监控并排期升级。
  • 如何判断漏洞是否已被在野利用？
    • 查威胁情报平台（CISA KEV、厂商公告、CNVD、威胁情报源）、社区讨论（GitHub PoC）、监控自有系统的异常行为（日志、外连）。CISA KEV 目录是被确认利用漏洞的权威清单。
  • 高危漏洞的"黄金 72 小时"指什么？
    • 漏洞公开后到被大规模利用的窗口期通常很短（高危漏洞可能数小时即被利用）。所以处置要快：评估→遏制→修复在最短时间完成，这也是"补丁管理自动化"和"应急演练"重要的原因。

• 扩展信息

  • 漏洞处置相关资源：
    • CVE（通用漏洞披露）/ CNVD（国家漏洞库）
    • CISA KEV（被利用漏洞目录）
    • 各厂商安全公告（Red Hat、Microsoft、Apache 等）
    • 漏洞管理工具：Nessus、OpenVAS、Qualys、Trivy（容器）
  • 补丁管理最佳实践：
    • 建立资产/补丁基线、定期扫描、灰度发布（先测试环境→试点→全量）
    • 紧急漏洞走特殊流程（不受常规变更窗口限制）

🤔 如何防范 SSH 密码暴力破解攻击？

• SSH 暴力破解的防护核心是"减少攻击面 + 提高破解成本 + 及时阻断”：密钥认证替代密码、禁用 root 远程登录、限源/限端口、登录失败锁定（fail2ban）、端口混淆与监控告警多层叠加。

  • 第一层：减少攻击面（最有效）

    • 密钥认证替代密码：PasswordAuthentication no，用 SSH Key 登录（密钥极难在线爆破）
    • 禁用 root 远程登录：PermitRootLogin no（root 用普通用户 + sudo）
    • 限制可登录用户：AllowUsers/AllowGroups 白名单
    • 限制来源 IP：sshd_config 里 Match Address 或防火墙只允许办公网段
    • 修改默认端口 22（可降低扫描器命中率，但非关键防御）

  • 第二层：提高破解成本

    • 登录失败锁定：fail2ban（自动封禁多次失败 IP）或 pam faillock
    • 密码策略：强密码、禁止常见密码、定期更换
    • 延迟机制：MaxAuthTries（限制尝试次数）、LoginGraceTime（限制登录窗口）
    • 多因素认证（MFA）：Google Authenticator 等，即使密码泄露也进不去

  • 第三层：及时阻断与发现

    • fail2ban 自动封禁（sshd jail）
    • 监控告警：日志集中收集，异常登录（失败次数、陌生 IP、陌生时段）触发告警
    • 异常行为分析：同一 IP 高频登录失败、批量 IP 扫描
    • 蜜罐：部署 SSH 蜜罐（如 cowrie）诱捕攻击者

  • 具体配置示例

    1 2 3 4 5 6 7 8 9 10

    # /etc/ssh/sshd_config PasswordAuthentication no # 禁用密码登录 PermitRootLogin no # 禁用 root 远程 AllowUsers ops # 只允许指定用户（注意：AllowUsers 的 user@host 仅支持单一主机名/IP，不支持 CIDR） MaxAuthTries 3 # 最多 3 次尝试 LoginGraceTime 30 # 30 秒内完成登录 # 按来源网段限制（需用 Match Address 块，而非 AllowUsers） Match Address 10.0.0.0/8 PasswordAuthentication yes

• 协助记忆

  • 防护四板斧：“密钥登录（釜底抽薪）、禁 root、限源限用户、fail2ban 封禁”。
  • 核心逻辑：“密码是弱项（会被爆破），密钥是强项（无法爆破）"。

• 进阶思考

  • 为什么说"改 SSH 端口"不是关键防御？
    • 改端口只能降低"扫描命中率”（自动扫描默认找 22），但针对性攻击者扫描全端口很快能找到；且换端口不能替代真正的防护（密钥、限源）。它是"降低噪音"而非"提高安全"。
  • fail2ban 和 pam faillock 有什么区别？
    • fail2ban：用户态程序，监控日志中失败尝试，达到阈值后用防火墙（iptables/nftables）封禁 IP，作用于网络层，对全服务有效
    • faillock：PAM 模块，对单个账号锁定（防针对单账号），作用于登录层
    • 两者可叠加：faillock 锁单账号（防被爆破）、fail2ban 封攻击者 IP。
  • 密钥认证就绝对安全吗？有什么坑？
    • 密钥本身安全，但要注意：①私钥泄露（保管/权限 600）②私钥无口令保护（被盗即用）③~/.ssh/authorized_keys 被篡改（加后门公钥）。所以密钥也要管好：加口令、权限收紧、定期审计 authorized_keys。

• 扩展信息

  • fail2ban 基本配置：
    1 2 3 4 5 6

    # /etc/fail2ban/jail.local [sshd] enabled = true maxretry = 5 # 5 次失败 bantime = 3600 # 封禁 1 小时 findtime = 600 # 10 分钟窗口

  • SSH 加固其他项：
    • AllowTcpForwarding no（关闭端口转发，防止隧道后门）
    • X11Forwarding no、PermitEmptyPasswords no、ClientAliveInterval（存活探测，超时无响应才断开，需配合 ClientAliveCountMax，并非空闲断开）

🤔 如何确保备份数据的安全性？

• 备份安全的核心是"3-2-1 原则 + 加密 + 隔离 + 验证"：至少 3 份备份、2 种介质、1 份异地/离线；备份数据加密存储（防泄露）、与生产环境隔离（防勒索加密）、定期恢复演练（验证可用性）。

  • 备份策略（3-2-1 原则）

    • 3 份数据：原始 + 2 份备份
    • 2 种介质：不同存储技术（如磁盘 + 磁带、磁盘 + 对象存储），防同源故障；“异地"属第 3 条的位置维度，不要与介质混淆
    • 1 份异地/离线：异地容灾或离线存储（防单点故障/勒索）
    • 延伸：3-2-1-1（加 1 份不可变/离线）防勒索

  • 备份加密（防泄露）

    • 备份数据加密存储：备份工具加密（如 restic/borg 原生加密）、或加密介质（LUKS）、或加密文件（gpg）
    • 传输加密：备份传输走加密通道（SSH/HTTPS/VPN）
    • 密钥管理：加密密钥单独保管（KMS/密码管理器），备份与密钥分离

  • 备份隔离（防勒索/防篡改）

    • 备份存储与生产隔离：独立网络/独立账号（防勒索软件横向加密备份）
    • 不可变备份（Immutable）：对象存储开启版本控制/不可变锁（WORM），备份不被篡改/删除
    • 离线备份：磁带/离线盘（勒索无法触及）
    • 最小权限：备份账号只读写备份存储，不接触生产

  • 备份验证（防"备份失效”）

    • 定期恢复演练：实际恢复一次，验证可用性（“能恢复的备份才是备份”）
    • 备份完整性校验：校验和、日志检查
    • 监控备份任务：失败告警（备份没跑成功 = 没有备份）

  • 访问控制与审计

    • 备份存储访问控制（最小权限 + 多因素）
    • 备份操作审计（谁备份、谁恢复、谁访问）
    • 备份数据脱敏（如备份含敏感数据，考虑脱敏）

• 协助记忆

  • 备份安全口诀：“3-2-1 原则 + 加密防泄露 + 隔离防勒索 + 演练保可用”。
  • 一句话：“备份要分几份、要加密、要隔开、要能恢复”。

• 进阶思考

  • 为什么备份数据也要加密？它又不是明文在前台？
    • 因为备份存储往往是"大数据集中点"，一旦泄露影响巨大（数据库备份含全部数据）；且备份可能被窃取（介质丢失/被盗）。加密备份 + 密钥分离，让"偷到备份也用不了"。
  • 不可变备份（WORM）为什么是防勒索的关键？
    • 勒索软件会加密一切可写的备份。不可变备份（对象锁/WORM）在锁定期内不可修改/删除，勒索无法破坏，恢复时就有干净副本。这是"3-2-1-1"里第 4 个"1"的价值。
  • 如何验证备份真的可用？
    • 定期（如每月）做一次实际恢复演练：从备份恢复到一个隔离环境，验证数据完整性和可启动性，并记录演练结果。“备份成功”（备份任务跑完）≠“能恢复”（恢复成功）。

• 扩展信息

  • 常用备份工具对比：
    • restic：加密 + 去重 + 增量 + 云存储（现代推荐）
    • borgbackup：去重 + 加密（类似 restic）
    • rsync：同步备份（无内置加密，需结合加密层）
    • xtrabackup（MySQL）/ pg_dump（PostgreSQL）：数据库备份
    • 对象存储（S3 + 版本控制/对象锁）：不可变备份
  • 备份安全检查清单：
    • 是否有 3-2-1（异地离线）？是否有加密？是否有不可变？是否有恢复演练？是否有备份监控告警？密钥是否与备份分离保管？

🤔 业务出现大规模 DDoS 攻击，该怎么处理？

• DDoS 处置分"事前防护 + 事发响应 + 事后复盘"：事发时核心是"隔离攻击流量 + 保留业务可用"——确认攻击类型 → 启用防护（流量清洗/黑洞/限速）→ 切换高防（CDN/高防 IP）→ 协同 ISP 处置 → 事后加固与预案优化。

  • 事前防护（预防）

    • 接入高防：云高防 IP、具备 DDoS 清洗能力的高防 CDN（隐藏源站 IP；普通 CDN 抗大流量能力有限）
    • 带宽冗余：入口带宽留有余量
    • 限速限流：业务层限流、连接数限制、SYN Cookie
    • 监控告警：流量基线监控（突发告警）、DDoS 监测

  • 事发响应（处置）

    • 第一步：确认攻击
      • 确认是否真被攻击：ss -antp（TCP）/ss -anu（UDP）看连接、iftop/nload 看流量、监控面板（UDP Flood/反射放大类需看 UDP 连接）
      • 识别攻击类型：流量型（SYN Flood/UDP Flood/反射放大）还是应用型（CC）
    • 第二步：止血
      • 启用流量清洗（云清洗/运营商清洗）：把攻击流量过滤掉
      • 黑洞路由（Blackhole）：对攻击目标 IP 做黑洞（牺牲单 IP 保全网，紧急手段）
      • 限速：入口限速、单 IP 限速、连接数限制
      • SYN Cookie/半连接防护：应对 SYN Flood
    • 第三步：切换/调度
      • 域名切到高防 CDN（隐藏源站，清洗后转发）
      • 切换备用 IP/备用线路（运营商多线）
      • 若被持续打源站，联系运营商/云厂商协助（加清洗能力）
    • 第四步：恢复与验证
      • 确认清洗后业务恢复、验证可用性
      • 持续监控是否二次攻击

  • CC 攻击处置（应用层）

    • WAF 规则拦截（UA 过滤、频率限制）
    • 业务层限流（限 IP 请求频率、限 QPS）
    • 验证码/挑战（人机识别）
    • 静态化/缓存（降低应用压力）

  • 事后复盘

    • 分析攻击类型、规模、来源（攻击溯源）
    • 评估防护效果、成本（清洗费用、黑洞时间）
    • 优化防护策略、预案演练

• 协助记忆

  • 处置三阶段：“事前（高防+监控）、事发（清洗+黑洞+切换）、事后（复盘+预案）"。
  • 关键口诀：“先确认、再止血（清洗/黑洞）、后切换（高防）、终复盘”。

• 进阶思考

  • 黑洞路由（Blackhole）的代价是什么？
    • 黑洞是把攻击 IP 的所有流量（含正常业务）直接丢弃，相当于"断臂求生”：单个 IP 完全不可用，但保住了同机柜/同网段其他服务的可用性。所以黑洞是紧急手段，需尽快切高防恢复。
  • 如何隐藏源站 IP 防 DDoS？
    • 域名解析到高防 IP/CDN，源站不暴露公网 IP（只允许高防回源）。同时注意：①源站不要做 NS 记录/证书泄露（Cert 日志能反查源站 IP）②源站只开 443/高防回源 IP 白名单。
  • 为什么云清洗/运营商清洗能"扛住"大流量？
    • 清洗中心有海量带宽和清洗设备，攻击流量先到清洗中心（通过 BGP 引流/Anycast），被识别过滤后再转发干净流量给源站。源站只需承受干净流量，从而"以小博大"。

• 扩展信息

  • DDoS 常见攻击类型：
    • SYN Flood（半连接耗尽）、UDP Flood（带宽耗尽）、反射放大（DNS/NTP/SSDP/CharGEN）、HTTP Flood/CC（应用层）、Slowloris（慢连接占用）
  • 防护产品/手段：
    • 云高防（阿里云 DDoS 高防、腾讯云大禹）、CDN（Cloudflare、阿里云 CDN）、运营商清洗、自建清洗（BGP FlowSpec）

🤔 如何制定公司运维安全策略？

• 运维安全策略制定遵循"合规驱动 + 风险评估 + 分权制衡 + 全生命周期"：以安全基线/合规要求为起点 → 风险评估确定重点 → 覆盖账号权限、网络边界、漏洞补丁、日志审计、应急响应、数据安全六大域 → 用制度 + 流程 + 技术工具落地。

  • 第一步：明确依据与目标

    • 合规驱动：等保 2.0、ISO 27001、行业监管要求（金融/医疗/政府）
    • 风险评估：识别关键资产、威胁、脆弱点（哪些系统最重要？风险最高？）
    • 目标：机密性、完整性、可用性（CIA）的平衡

  • 第二步：六大安全域落地

    • 账号权限：最小权限、账号生命周期（入职/离职/调岗）、特权账号管理（PAM）、双人复核
    • 网络边界：防火墙策略、内网分段、DMZ、VPN/堡垒机接入
    • 漏洞补丁：资产清点、定期扫描、补丁管理流程、高危漏洞应急
    • 日志审计：日志集中收集、保留期限、安全事件告警（SIEM）
    • 应急响应：应急预案、事件分级、演练、取证与复盘
    • 数据安全：数据分级、加密（传输/存储）、备份、防泄露（DLP）

  • 第三步：制度与流程落地

    • 安全制度：账号管理制度、变更管理制度、应急预案、安全基线文档
    • 流程：审批流（变更、发布、权限申请）、审计流（日志、操作）、应急流（事件上报）
    • 工具：堡垒机（操作审计）、配置管理（CMDB）、自动化（Ansible 加固）

  • 第四步：运行与改进

    • 定期安全检查（基线核查、渗透测试）
    • 安全培训与意识教育（全员 + 运维专项）
    • 持续改进（PDCA：发现短板→改进→再验证）

• 协助记忆

  • 策略框架口诀：“依合规、做评估、六大域、成闭环”。
  • 六大域：“账号、网络、漏洞、日志、应急、数据”。

• 进阶思考

  • 为什么"分权制衡"对运维安全很重要？
    • 避免"运维一个人说了算"导致的风险：①滥用权限（删库/改数据）②被钓鱼后单点失守。分权：关键操作需双人复核（如生产变更）、堡垒机记录审计、特权账号定期轮换，让"想做坏事的人做不了，做了有记录"。
  • 等保 2.0 对运维侧的核心要求是什么？
    • 等保 2.0 是国标 GB/T 22239，运维侧要点：①身份鉴别（双因素、账号唯一）②访问控制（最小权限、三员分立：系统管理/安全管理/审计管理）③安全审计（日志留存，配合《网络安全法》第 21 条等要求）④入侵防范（恶意代码防护、漏洞扫描）⑤数据安全（加密、备份恢复）。做等保是很多企业（尤其政府和金融）的合规刚需。
  • 安全策略如何"落地"而不只是"文档"？
    • 关键是"制度 → 工具 → 流程"三层绑定：制度规定了要求，工具强制执行（堡垒机、权限系统），流程保障执行（审批、审计）。再加"检查-考核"（定期审计、违规通报），让策略真正运转而非束之高阁。

• 扩展信息

  • 常用安全框架/标准：
    • 等保 2.0（GB/T 22239）、ISO 27001（信息安全管理体系）、NIST 网络安全框架（CSF）、CIS Controls
  • 安全制度文档清单：
    • 安全管理制度、账号权限管理制度、变更管理制度、应急预案与演练计划、数据分类分级办法、安全基线（CIS/等保基线）

🤔 怎么防止将代码上传到公网代码仓库？

• 防止代码泄露到公网的核心是"制度约束 + 技术阻断 + 泄露检测"：明确仓库使用规范 → 内网代码托管/接入网关管控外发 → 代码扫描（密钥/敏感信息）→ 定期外网泄露检测（GitHub 搜索/监控）。

  • 制度层面（源头约束）

    • 明确规范：内网代码必须托管在内网 Git（GitLab/Gitea），公网仓库仅允许开源/公开项目
    • 培训宣导：员工签署保密协议，明确代码外传红线
    • 审批流程：确有外发需求（开源贡献、合作）需审批，且脱敏后外发

  • 技术阻断（技术兜底）

    • 网络管控：代码托管服务器只走内网，公网无法直接访问；外网仓库（GitHub）域名在公司网络管控/审计
    • 代码托管集成：内网 GitLab 设置"禁止创建公开项目"（管理员默认项目可见性级别）；“禁止 push 到外网仓库"需靠网络出口管控（防火墙/DLP/终端管控）实现，GitLab 无内置开关
    • 终端管控：DLP（防泄露系统）监控 git 外发行为；限制通过邮箱/网盘外传代码
    • 凭据管理：私有仓库用部署密钥/凭据管理，不写入代码

  • 代码扫描（事前发现）

    • 提交前扫描：Git 钩子/CI 流水线集成密钥扫描（防止把 AK/SK、密码提交上去）
    • 工具：gitleaks、trufflehog、GitLab Secret Detection、GitHub Secret Scanning
    • 敏感信息检查：注释中的内网地址、数据库连接串、私钥

  • 泄露检测（事后发现）

    • 定期外网监控：搜索 GitHub/公网代码库中是否出现公司域名/内部项目名/特殊字符串
    • 工具：GitHub 代码搜索、gitleaks 扫描公开仓库、第三方泄露监控服务（如 GitGuardian）
    • 泄露处置：发现泄露立即删除/撤下、轮换泄露的密钥/凭据、溯源追责

• 协助记忆

  • 防泄露四道闸：“制度管人（规范）、网络管路（阻断）、扫描管码（发现）、检测管果（追责）"。
  • 一句话：“内网代码不外传、外发要审批、密钥不入库、泄露要监控”。

• 进阶思考

  • 为什么"密钥入库"是最高危的行为？
    • 一旦 AK/SK、数据库密码被提交到（哪怕是私有）仓库，就可能被扫描工具/离职人员/泄露事件暴露，攻击者用密钥直接接管云资源/数据库。所以密钥扫描是 CI 必检项，密钥泄露必须立即轮换。
  • git 操作能"撤回"已 push 的敏感信息吗？
    • 不能彻底撤回：git reset/revert 只能改本地/分支历史，已 push 的远端旧提交仍保留在远端对象库（GitHub 约 90 天后 GC），且他人已 clone 的副本无法撤销。正确做法：轮换密钥（不可逆），而非试图删除。
  • 私有代码仓库也可能泄露，如何防？
    • 私有仓库不等于绝对安全：账号泄露、员工离职、供应链攻击都可能暴露。防：①最小权限（仓库按需授权）②离职即回收 ③私有仓库也做敏感信息扫描 ④重要代码加密/模块化隔离（关键算法单独库）。

• 扩展信息

  • 密钥扫描工具：
    • gitleaks：git 历史密钥扫描（最常用）
    • trufflehog：深度密钥扫描
    • GitLab/GitHub 内置 Secret Detection
    • GitGuardian：第三方泄露监控服务
  • Git 提交前拦截示例（pre-commit 钩子）：
    1 2 3

    # gitleaks 新语法（v8.19+，旧 detect/protect 已弃用） gitleaks git --pre-commit --staged --redact # 或用 pre-commit 框架官方 hook

🤔 如何防止 USB 设备传播病毒？

• 防止 USB 传播病毒的核心是"管控接入 + 设备消毒 + 终端防护”：禁用/白名单管控 USB 存储设备接入 → 对必要接入的 U 盘先查毒/隔离 → 终端装杀毒（EDR）和自动运行防护（Autorun）→ 内外网物理隔离和制度配合。

  • 接入管控（防设备接入）

    • 禁用 USB 存储：Linux 黑名单 usb-storage 驱动；Windows 组策略禁用 USB 移动存储
    • 白名单管控：USB 设备管控软件（允许指定 VID/PID 的设备；注意 VID/PID 可被 BadUSB 固件伪造，只能作为纵深防御一环，不能绝对依赖）
    • BIOS 层面：可禁用 USB 端口（高安全环境）
    • 物理隔离：涉密/生产网与办公网物理隔离，USB 需经消毒中间机

  • 设备消毒（防介质携带）

    • 必要接入的 U 盘先查毒（杀毒软件全盘扫描）
    • 专用"消毒机”：只装杀毒+系统还原，所有外来 U 盘先在此消毒
    • 禁止外来 U 盘直接接入生产/涉密系统

  • 终端防护（防传播链）

    • 终端杀毒/EDR：实时防护 + 可移动存储扫描
    • 关闭自动运行（Autorun）防 U 盘病毒自动执行：注意自 Windows 7 起系统对 USB 可移动介质默认忽略 autorun.inf（“插入即自动执行"主要是 XP 时代场景），现代重点是关闭 **AutoPlay（自动播放）**的自动打开/查看等选项（组策略：关闭自动播放）
    • 最小权限：普通用户不能安装/执行未知程序
    • 系统补丁：及时打补丁（防 U 盘蠕虫利用漏洞）

  • 制度与意识

    • USB 使用规范（谁用、什么用途、登记）
    • 安全意识培训（不随便插来历不明的 U 盘）
    • 违规处罚与审计

• 协助记忆

  • 防 USB 病毒口诀：“管接入（禁用/白名单）、先消毒（查毒）、关自动（Autorun）、装防护（EDR）"。
  • 关键认知：“U 盘病毒曾靠 Autorun 自动传播，现在主要靠用户主动运行/漏洞利用；防御靠管控接入 + 杀毒拦截 + 禁用存储”。

• 进阶思考

  • 为什么"关闭自动运行（Autorun）“能防 USB 病毒？
    • 早期很多 USB 病毒（蠕虫）利用 Windows 自动播放/Autorun 功能：插入 U 盘即自动执行 autorun.inf 指向的恶意程序（主要影响 Windows XP 时代）。自 Windows 7 起系统对 USB 可移动介质默认忽略 autorun.inf，现代重点是关闭 AutoPlay 的自动打开/查看选项 + 杀毒实时防护，让用户不主动运行就不中招。
  • Linux 服务器需要防 USB 病毒吗？
    • 需要。①Linux 也会被 USB 攻击（如 BadUSB——固件级恶意设备、含 Linux 病毒的 U 盘）②服务器常被插运维 U 盘（补丁/工具），是传播链一环。所以服务器也应禁用 USB 存储（尤其生产/涉密），或用白名单。
  • BadUSB 和普通 U 盘病毒有什么区别？
    • 普通 U 盘病毒：恶意文件在 U 盘，可被杀毒拦截
    • BadUSB：恶意固件在 U 盘主控芯片里（模拟键盘输入命令），杀毒看不到文件，普通防护无效。防御：管控 USB 设备接入（白名单 VID/PID）、禁止陌生 U 盘。

• 扩展信息

  • Linux 禁用 USB 存储：
    1 2 3 4

    modprobe -r usb-storage # 卸载驱动（新内核 U 盘可能走 uas 驱动，需一并处理） echo 'blacklist usb-storage' >> /etc/modprobe.d/blacklist.conf # 永久禁用 echo 'blacklist uas' >> /etc/modprobe.d/blacklist.conf # 更彻底：udev 规则 / USBGuard / BIOS 层禁用

  • Windows 禁用 USB 存储（组策略）：
    • 计算机配置 → 管理模板 → 系统 → 可移动存储访问 → 所有可移动存储类：拒绝所有权限
  • USB 管控工具：
    • 商用：USB 管控/外设管控软件（DLP 外设管控模块）
    • 免费：组策略/黑名单驱动 + 杀毒软件

🤔 内网疑似 ARP 攻击，怎么解决？

• ARP 攻击（ARP 欺骗/中毒）的解决分"检测 → 定位 → 防御 → 加固”：用抓包/ARP 表异常检测攻击 → 定位攻击源（MAC/端口）→ 交换机开启防 ARP 攻击特性（DAI/DHCP Snooping/端口安全）+ 终端静态绑定 → 排查中毒终端杀毒。

  • 第一步：确认与检测

    • 现象：网络时通时断、网关被"顶替”、某台机器频繁断网、ARP 表跨主机比对出现同一 IP 对应多个 MAC（或网关 MAC 频繁抖动）
    • 检测命令：
      1 2 3 4

      arp -a # 看 ARP 缓存，同一 IP 是否多个 MAC arping -I eth0 <网关IP> # 看网关 MAC 是否变化 # 抓包看 ARP 应答风暴 tcpdump -i eth0 -nn arp

    • 工具：arpwatch（监控 ARP 表变化）检测；ettercap 是主动 ARP 欺骗攻击工具（可用于渗透测试演示），不是检测工具

  • 第二步：定位攻击源

    • 根据异常的 MAC 地址，在交换机上查 show mac address-table | include <MAC> 定位端口
    • 断开该端口/下线终端，验证网络恢复
    • 检查该终端是否中毒（杀毒、查 ARP 进程/工具）

  • 第三步：交换机层防御（治本）

    • DAI（Dynamic ARP Inspection）：基于 DHCP Snooping 绑定表，校验 ARP 包合法性，拦截非法 ARP 应答
    • DHCP Snooping：信任/非信任端口区分，防 DHCP 和 ARP 欺骗
    • 端口安全（Port Security）：限制单端口 MAC 数，防 MAC 泛洪
    • IP-MAC 绑定：交换机静态绑定（ip dhcp snooping binding <MAC> vlan <VLAN> <IP> interface <INT> 完整参数，或端口静态 MAC）

  • 第四步：终端层防御

    • 网关静态绑定：终端上把网关 IP 与 MAC 静态绑定（防网关被顶替）
      1 2	arp -s <网关IP> <正确MAC> # Linux 静态绑定 # Windows: arp -s 也支持（需管理员）

    • 安装防 ARP 攻击软件/杀毒（终端侧防护）
    • 排查中毒终端：杀毒、重装系统

  • 第五步：加固与预防

    • 全网启用 DHCP Snooping + DAI（核心防御）
    • 终端统一安全基线、强制杀毒
    • 定期检测 ARP 表异常（arpwatch 监控）

• 协助记忆

  • ARP 攻击处置口诀：“检测（看 MAC）、定位（查端口）、防御（DAI/绑定）、杀毒（清终端）"。
  • 关键认知：“治本是交换机开 DAI + DHCP Snooping，终端绑定网关是治标”。

• 进阶思考

  • 为什么 DHCP Snooping 和 DAI 能防 ARP 攻击？
    • DHCP Snooping 建立"IP→MAC→端口"的信任绑定表（非信任端口只允许 DHCP 请求，不信任其上报的 IP/MAC）。DAI 用这张表校验每个 ARP 包的"发送方 IP+MAC"是否匹配绑定表，不匹配就丢弃，从而拦截伪造的 ARP 应答（ARP 欺骗的核心是伪造发送方地址）。
  • 终端静态绑定网关为什么不彻底？
    • 静态绑定只保护"本机到网关"不被顶替，但①攻击者仍可欺骗其他终端 ②静态绑定配置维护麻烦（网关 MAC 变更要全改）③治标不治本。真正根治是在交换机上做 DAI/DHCP Snooping。
  • ARP 攻击只能在内网发生吗？
    • 是。ARP 只在同一广播域（二层网段）内有效，攻击者必须在同一内网（或已进入内网）才能发起。所以 ARP 攻击常与"内网失陷”（某终端被攻破）相关，是横向移动的手段之一，也提醒内网同样要分段隔离。

• 扩展信息

  • 交换机防 ARP 攻击配置（思科风格）：
    1 2 3 4 5 6 7 8

    ip dhcp snooping # 全局开启 ip dhcp snooping vlan 10 # 指定 VLAN interface Gig0/1 ip dhcp snooping trust # 上行/服务器端口设信任 interface Gig0/2 ip dhcp snooping limit rate 10 # 非信任端口限速 ip arp inspection vlan 10 # 开启 DAI ip arp inspection validate src-mac dst-mac ip # 校验字段

  • 华为设备对应命令：dhcp snooping enable、arp anti-attack（arp anti-attack check user-bind）等

🤔 网站突然出现大量异常请求，该如何处理？

• 大量异常请求处置遵循"观察分析 → 分类定性 → 针对性阻断 → 复盘加固”：先抓取/统计请求特征（来源 IP、UA、路径、频率、行为）判断是爬虫/CC 攻击/漏洞扫描/业务异常，再对症下药（限流/WAF/封 IP/黑名单），最后复盘加固。

  • 第一步：观察与数据采集（先看清）

    • 看访问日志：tail -f access.log、按 IP 统计请求量
    • 抓包：tcpdump -i eth0 -nn 'port 80'（看请求内容）
    • 监控面板：QPS 趋势、错误率、连接数
    • 采样异常请求的完整信息（IP、UA、Referer、请求路径、参数、时间）

  • 第二步：分析分类（定性）

    • 爬虫：UA 特征（Python-requests、Go-http-client、搜索引擎蜘蛛）、规律频率、大量 GET
    • CC 攻击：大量合法请求刷动态接口、分布 IP（肉鸡）、高频、模拟浏览器 UA
    • 漏洞扫描：请求路径含扫描特征（/admin、/.env、?id= 遍历、SQL 注入特征）
    • 业务异常：某个功能被大量调用（刷接口/薅羊毛）
    • 恶意刷接口：注册、登录、下单等被批量调用

  • 第三步：针对性阻断（对症）

    • 限流：Nginx limit_req（单 IP QPS）、limit_conn（连接数）
    • WAF 规则：封 UA、封路径、封 IP 段、人机验证
    • 封禁：iptables/fail2ban 封异常 IP/网段
    • 应用层：验证码（关键接口）、频率限制（登录/注册）、风控
    • CDN/WAF 层：云端 DDoS/WAF 防护，清洗异常流量

  • 第四步：复盘与加固

    • 分析攻击来源、目的、手法
    • 加固：接口鉴权、限流策略常态化、监控告警（QPS 突增告警）
    • 更新黑名单/防护规则、应急预案

• 协助记忆

  • 处置四步：“看清（抓数据）→ 定性（分类）→ 阻断（限流封禁）→ 加固（复盘）"。
  • 分类口诀：“爬虫看 UA、CC 看频率、扫描看路径、刷量看业务”。

• 进阶思考

  • 如何区分"正常业务高峰"和"异常请求”？
    • 看特征：①来源 IP 分布（正常用户分散，攻击集中/肉鸡多 IP）；②请求模式（正常有交互逻辑，攻击高度重复）；③关键路径命中（正常不会反复刷动态接口）；④UA/行为（攻击 UA 单一或伪造）。结合历史基线（QPS 正常波动范围）判断。
  • 为什么要先分析再封禁？直接封 IP 不行吗？
    • 盲目封 IP 可能：①误伤正常用户（动态 IP、共享出口 NAT）②CC 攻击 IP 是肉鸡海量分散，封不过来 ③爬虫封 IP 后会换 IP 再来。所以先定性：爬虫/扫描用 WAF 规则和验证码，CC 用限流+清洗，封 IP 只是辅助。
  • Nginx 限流如何配置？
    • limit_req_zone 定义限流区（按 IP/其他键），limit_req 应用：limit_req_zone $binary_remote_addr zone=req:10m rate=10r/s; + limit_req zone=req burst=20 nodelay;。burst 允许突发，nodelay 不排队。

• 扩展信息

  • Nginx 限流配置示例：
    1 2 3 4 5 6 7 8 9

    http { limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s; server { location /api/ { limit_req zone=api burst=20 nodelay; proxy_pass http://backend; } } }

  • 日志分析命令：
    1 2 3

    awk '{print $1}' access.log | sort | uniq -c | sort -rn | head # 按 IP 请求量（$1 是客户端 IP） awk '{print $6}' access.log | sort | uniq -c | sort -rn | head # 按请求路径分布 # UA 在 combined 格式下字段靠后（约 $12），可先用日志分析工具或先拆字段确认列序再统计

🤔 安全扫描发现某应用存在 Log4j 漏洞，但暂时无法升级，如何临时防护？

• Log4j 漏洞（Log4Shell，CVE-2021-44228）临时防护遵循"阻断入口 + 缓解机制 + 增强监控"：最有效是给 JVM 加参数 -Dlog4j2.formatMsgNoLookups=true（彻底关闭 Lookup）或升级 log4j-core；无法升级时的临时缓解包括加 JVM 参数、升级到 2.15.0/2.16.0、配置 log4j2.formatMsgNoLookups、WAF 拦截特征、移除 JndiLookup 类、限制出站。

  • 漏洞原理（理解为什么这样防）

    • Log4j 日志库在处理 ${jndi:ldap://...} 格式的消息时会触发 JNDI Lookup，攻击者构造恶意字符串（日志中记录的用户输入）即可远程加载恶意代码（RCE）
    • 关键：攻击入口是"日志消息中的 ${jndi:...} 字符串"，所以防护围绕"禁用 Lookup + 拦截恶意输入"

  • 临时防护措施（按推荐度）

    • ① 加 JVM 参数（最有效，需重启生效）：
      1 2 3

      # 启动参数关闭消息 lookup（仅对 log4j2 >= 2.10 生效；低于 2.10 需删除 JndiLookup 类） -Dlog4j2.formatMsgNoLookups=true # 注意：只关闭消息中的 ${...} lookup；2.15.0 起该参数不再需要（默认关闭），2.16.0 彻底移除 lookup

    • ② 升级 log4j-core（治本）：升到 2.17.0+（2.15.0 仅缓解仍被绕过，2.16.0 移除 lookup，2.17.0 修复完整）；Java 7 环境升 2.12.2/2.12.3
    • ③ 移除 JndiLookup 类（高级缓解，低版本唯一手段）：删除 org/apache/logging/log4j/core/lookup/JndiLookup.class（注意正确路径，org.apache.log4j 是 log4j 1.x 命名空间）
    • ④ 配置文件方式：在 classpath 下放 log4j2.component.properties 写 log4j2.formatMsgNoLookups=true，或设环境变量 LOG4J_FORMAT_MSG_NO_LOOKUPS=true（⚠️ 不要写进 log4j2.xml，该属性不从那读，写了无效）
    • ⑤ WAF 层拦截：拦截请求/日志中的 ${jndi: 特征（多层编码绕过要注意，需多层解码规则）
    • ⑥ 限制出站：封禁应用出站 LDAP/RMI（阻断 JNDI 回连恶意服务器）

  • 注意事项

    • 临时防护不彻底：攻击者可用编码绕过 WAF 特征、可用其他入口（日志来源多）
    • 临时缓解后仍要尽快升级（治本）
    • 排查是否已被利用（日志中搜 ${jndi: 特征、LDAP 出站记录）

  • 处置流程

    1 2 3

    确认受影响版本（log4j-core < 2.17.0）→ 能升级则升级 → 不能升级：加 JVM 参数（首选）+ WAF 拦截 + 出站限制 → 排查是否已被利用 → 持续监控 → 尽快排期升级

• 协助记忆

  • Log4Shell 口诀：“JNDI 查名字（lookup），日志消息是入口，加参数（formatMsgNoLookups）最有效，升级 2.17 治本”。
  • 防护优先级：“JVM 参数 → 升级 → WAF → 出站限制”。

• 进阶思考

  • 为什么 -Dlog4j2.formatMsgNoLookups=true 是最有效的临时手段？
    • 它直接关闭了 log4j2 的"消息 Lookup"功能（消息中 ${...} 的解析），攻击者构造的 ${jndi:ldap://...} 会被当作普通字符串打印而不会触发 JNDI。这是"釜底抽薪"，比 WAF 特征拦截更根本（不依赖特征匹配）。注意前提：该参数仅对 log4j2 ≥2.10 生效，且需重启 JVM；它只关闭消息 lookup，配置/其他来源的 ${jndi:...} 仍可能解析。
  • 为什么 2.15.0 之后还要升级到 2.16.0/2.17.0？
    • 2.15.0 只是默认关闭 lookup（formatMsgNoLookups 默认 true），但仍有绕过路径（如某些版本不生效）；2.16.0 彻底移除了 lookup 功能；2.17.0 修复了 2.16 的 DoS 漏洞（CVE-2021-45105）。所以完整修复是 2.17.0+。
  • 如何排查 Log4j 是否已被利用？
    • ①日志中搜 ${jndi:/${rmi:/${ldap: 特征；②查应用出站连接（ss -antp 看 LDAP 389/RMI 1099 出站）；③查 DNS 查询记录（攻击常触发恶意域名解析）；④查进程/文件新增的可疑内容（回连下载的 payload）。

• 扩展信息

  • Log4Shell 时间线与版本：
    • CVE-2021-44228（Log4Shell，RCE，2021-11 私密上报，2021-12-09/10 公开披露并大规模利用）
    • 修复版本：2.15.0（缓解）→ 2.16.0（移除 lookup）→ 2.17.0（完整修复）
    • 后续：CVE-2021-45046（2.15 绕过）、CVE-2021-45105（2.16 DoS）
  • 检测工具：
    • 扫描：log4j-scan（社区）、各厂商漏洞扫描器
    • 依赖检查：mvn/gradle 依赖树查 log4j-core 版本、SCA 工具

🤔 老旧业务不支持 HTTPS，如何推进全站加密改造？

• 推进老旧业务 HTTPS 改造的核心是"兼容迁移 + 成本控制 + 分阶段推进"：用网关/代理统一加解密（不改业务代码）→ 证书自动化（Let’s Encrypt/证书管理）→ 兼容旧客户端 → 分阶段灰度迁移 → 全站强制 HTTPS + HSTS。

  • 现状分析（先摸清）

    • 盘点存量业务：哪些不支持 HTTPS？为什么？（代码硬编码 http、混合内容、证书缺失、依赖）
    • 评估改造成本：改代码 vs 网关代理
    • 识别不可改造点：旧客户端不支持 TLS、内网明文依赖

  • 方案一：网关/代理统一加密（最快，不改代码）

    • Nginx/HAProxy 前置做 TLS 终结，后端仍是 HTTP（内网明文）
    • 优点：业务代码零改动、快速上线 HTTPS
    • 缺点：后端到网关间是明文（内网风险需评估），网关需处理证书
    • 配置示例（Nginx TLS 终结）：
      1 2 3 4 5 6 7 8

      server { listen 443 ssl; ssl_certificate /etc/nginx/cert/fullchain.pem; ssl_certificate_key /etc/nginx/cert/privkey.pem; location / { proxy_pass http://backend; # 后端仍是 HTTP } }

  • 方案二：应用层改造（彻底，改代码）

    • 应用启用 HTTPS：改代码、配置 TLS、处理混合内容（页面里 http 资源改 https）
    • 成本高但彻底，适合核心/长期业务

  • 证书管理

    • 证书获取：Let’s Encrypt（免费自动签发）、云厂商证书、企业内部 CA
    • 证书自动化：certbot 自动续期、acme.sh、证书管理平台（统一管理/监控过期）
    • 证书监控：过期告警（到期前 30/7 天告警）

  • 兼容与迁移

    • 旧客户端兼容：TLS 版本/算法兼容配置（兼顾安全与兼容的 TLS 1.2+，必要时临时放行弱协议过渡）
    • 分阶段迁移：先灰度（部分流量走 HTTPS）→ 逐步扩大 → 全量
    • 双栈过渡：同时支持 http/https，用 301 跳转逐步引导
    • 处理混合内容：页面资源（图片/JS/CSS）全部改 https，否则浏览器拦截

  • 收尾（强制 HTTPS）

    • 全站 301 跳转 http→https
    • 启用 HSTS（Strict-Transport-Security 头）强制浏览器走 HTTPS
    • 关闭明文入口（除必要兼容外）
    • 清理硬编码 http 链接

• 协助记忆

  • HTTPS 改造口诀：“网关兜底（不改代码）、证书自动（Let’s Encrypt）、分阶段迁（灰度）、强制跳转 + HSTS（收尾）"。
  • 成本与彻底权衡：“想快用网关，想彻底改应用”。

• 进阶思考

  • 网关 TLS 终结的"后端明文"风险如何管控？
    • 网关到后端之间是明文 HTTP，若内网被攻破，后端流量可被嗅探。管控：①网关与后端同内网、网络隔离（后端不暴露公网）②内网也走 TLS（mTLS/内部 HTTPS）③后端敏感接口强制 HTTPS。评估内网信任边界决定是否需要。
  • 为什么"分阶段灰度"比"一刀切"更适合老旧业务改造？
    • 老旧业务客户端多样（老浏览器/老设备）、可能有硬编码 http 依赖，一刀切会导致部分客户端无法访问。灰度迁移：先让新客户端走 HTTPS 验证无问题，再逐步切换，最后强制，把风险分散、可回滚。
  • 混合内容（Mixed Content）问题为什么必须处理？
    • HTTPS 页面里加载 http 资源（图片/JS/CSS）会被浏览器拦截（现代浏览器 Chrome 80+ 对活动内容直接拦截），且 JS 等活动内容被拦截会影响功能。所以改 HTTPS 必须同时把所有页面内资源改 https（或相对协议 //）。

• 扩展信息

  • Let’s Encrypt 证书自动续期：
    1 2 3

    certbot --nginx -d example.com # 自动获取+配置 certbot renew --dry-run # 测试续期 # 或 acme.sh 脚本

  • HSTS 配置示例（Nginx）：
    1	add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    • 提示：确认所有子域都支持 HTTPS 后再加 includeSubDomains（否则子域无法访问会出问题）；可加 preload 申请浏览器内置 HSTS 预加载列表
  • TLS 最佳实践参考：
    • TLS 1.2+、禁用弱算法（SHA1/RC4/3DES）、优先 ECDHE 套件、ssl_protocols/ssl_ciphers 配置
    • 参考 Mozilla SSL Configuration Generator / SSL Labs 评分

🤔 K8s 集群如何进行安全加固？

• K8s 安全加固覆盖"控制面 + 工作负载 + 网络 + 容器 + 供应链"五层：控制面（RBAC 最小权限、API 审计、证书管理）、工作负载（Pod 安全、镜像扫描）、网络（网络策略、加密）、容器（只读根文件系统/非 root/隔离）、供应链（镜像签名、SBOM）+ 运行时安全（Falco/运行时检测）。

  • 控制面加固

    • RBAC 最小权限：检查并显式禁用匿名访问（--anonymous-auth=false，注意 kube-apiserver 默认开启 anonymous auth，只是无 RBAC 绑定故危害有限）、最小权限绑定（Role/ClusterRole）、避免 cluster-admin 滥用
    • 服务账号：automountServiceAccountToken: false（默认不挂 token）、按需创建 SA
    • API 审计：启用 --audit-log-path 审计日志，监控敏感操作
    • 证书管理：控制面证书到期监控、定期轮换
    • API Server 访问控制：只允许必要来源（防火墙/NetworkPolicy）、HTTPS 强制

  • 工作负载加固（Pod）

    • Pod 安全标准（PSS）：restricted/baseline/privileged 分级，用 Pod Security Admission 强制
    • 安全上下文（SecurityContext）：非 root 运行（runAsNonRoot）、只读根文件系统（readOnlyRootFilesystem）、drop 所有 capability（drop: [ALL]）、allowPrivilegeEscalation: false
    • 禁止特权容器：privileged: false
    • 资源限制：requests/limits（防资源耗尽 DoS）
    • 只读/临时存储：emptyDir 按需只读挂载、限制宿主路径挂载（hostPath 高风险）

  • 镜像与供应链加固

    • 镜像扫描：Trivy/Clair/Anchore 扫描漏洞，阻止高危镜像部署
    • 镜像签名：cosign + Sigstore 验证镜像签名（防投毒）
    • SBOM：生成镜像软件物料清单
    • 私有仓库：从可信私有仓库拉取，禁用 latest 标签（用不可变 tag）
    • 镜像拉取策略：用固定 digest 或不可变 tag（不用 latest）；imagePullPolicy: IfNotPresent 只是"本地有就不拉”，并不防篡改，防篡改靠签名验证 + 可信私有仓库

  • 网络加固

    • NetworkPolicy：默认拒绝 + 最小放行（namespace 间隔离、Pod 间隔离）
    • 服务暴露最小化：ClusterIP 优先、NodePort 最小化、Ingress 控制
    • mTLS 加密：服务网格（Istio/Linkerd）做网格内加密
    • 控制面网络安全：API Server 防火墙/私网

  • 运行时安全

    • Falco：运行时异常行为检测（shell 进入容器、异常系统调用）
    • Seccomp/AppArmor：限制系统调用/应用行为
    • Secret 管理：Secret 用 KMS 加密（--encryption-provider-config，用 KMS v2，v1 已弃用）、外部 secret（External Secrets/Sealed Secrets）
    • 日志与审计：容器日志、审计日志集中收集分析

• 协助记忆

  • K8s 加固五层：“控制面（RBAC/审计）、工作负载（PSS/非root）、镜像（扫描/签名）、网络（策略/加密）、运行时（Falco/加密Secret）"。
  • 核心口诀：“最小权限（RBAC/非root）、最小暴露（网络策略）、供应链可信（扫描/签名）、运行时监控（Falco）"。

• 进阶思考

  • 为什么 Pod 要"非 root 运行”？
    • 容器默认以 root 运行（Dockerfile 未指定 USER），即使有容器隔离，一旦逃逸或被利用，root 权限危害巨大（可写宿主敏感文件、提权）。非 root + drop capabilities + 只读根文件系统，把"被攻破后的危害"降到最低。
  • RBAC 最小权限如何落地？
    • ①不用 cluster-admin 做日常操作 ②按角色拆分（developer 只读、operator 管理 namespace）③用 Role（namespace 级）而非 ClusterRole ④定期审计 RoleBinding/ClusterRoleBinding（kubectl auth can-i --list 自检）。
  • NetworkPolicy 为什么是默认拒绝而不是默认放行？
    • K8s 默认是"全通”（任何 Pod 可访问任何 Pod），一旦某个 Pod 被攻破即可横向移动。默认拒绝 + 显式放行，把攻击面缩到最小，是"零信任"思想在集群内的落地。

• 扩展信息

  • K8s 安全工具生态：
    • 镜像扫描：Trivy、Clair、Anchore、Grype
    • 签名：cosign（Sigstore）、Notary
    • 策略：OPA Gatekeeper、Kyverno（准入控制）
    • 运行时：Falco、kube-bench（CIS 基线检查）、kube-hunter（渗透测试）
    • 网络：Cilium、Calico（NetworkPolicy + 加密）
    • 审计：审计日志、Security Profiles Operator
  • CIS Kubernetes Benchmark：官方基线标准（控制面/工作负载/网络等多项检查），用 kube-bench 自动检查

🤔 你用过哪些安全产品 / 技术？有什么作用？

• 安全产品/技术按"防御纵深"分层：边界防护（防火墙/WAF/DDoS 高防）、主机防护（杀毒/EDR/HIDS）、网络监测（IDS/IPS/NTA）、身份与访问（堡垒机/4A/MFA）、漏洞与合规（扫描器/基线）、数据安全（DLP/加密）、日志与态势（SIEM/SOC）。回答时按层组织，说明"作用 + 部署位置 + 解决什么问题"。**

  • 边界防护层
    • 防火墙（Firewall）：网络层访问控制，放行/阻断 IP/端口。硬件（深信服/山石/H3C）或云安全组/云防火墙
    • WAF（Web 应用防火墙）：应用层防护，拦截 SQL 注入/XSS/CC/WebShell 等 Web 攻击
    • DDoS 高防：抗大流量攻击（清洗、高防 IP/CDN）
  • 主机防护层
    • 杀毒软件/EDR（终端检测响应）：恶意软件查杀、行为检测、应急响应
    • HIDS（主机入侵检测）：文件完整性、进程/登录监控（如 OSSEC、Wazuh、阿里云云安全中心）
    • 主机加固：安全基线、补丁管理
  • 网络监测层
    • IDS（入侵检测）：旁路监测流量，发现攻击特征后告警（不阻断）
    • IPS（入侵防御）：串联阻断恶意流量
    • NTA（网络流量分析）：异常流量/协议行为分析（如 Zeek）
  • 身份与访问层
    • 堡垒机（跳板机）：统一入口 + 操作审计 + 权限管控（如 JumpServer、齐治、帕拉迪、行云管家）
    • 4A 平台：认证（Authentication）、授权（Authorization）、账号（Account）、审计（Audit）
    • MFA（多因素认证）：账号+令牌/生物识别，防凭据泄露
  • 漏洞与合规层
    • 漏洞扫描器：定期扫描漏洞（Nessus、OpenVAS、AWVS、云扫描）
    • 基线核查：CIS/等保基线检查（kube-bench、安全基线工具）
    • 渗透测试：主动测试漏洞利用（红队/第三方）
  • 数据安全层
    • DLP（数据防泄露）：敏感数据外发监控/阻断（邮件/网盘/USB/打印）
    • 数据加密：传输（TLS/VPN）+ 存储（数据库/磁盘加密）
    • 备份与恢复：备份安全、异地容灾（防勒索）
  • 日志与态势层
    • SIEM（安全信息和事件管理）：日志集中 + 关联分析 + 告警（如 Splunk、ELK、Qradar）
    • SOC（安全运营中心）：7x24 监测响应（人 + 平台 + 流程）
    • 威胁情报：恶意 IP/域名/样本库（支撑检测和溯源）

• 协助记忆

  • 分层口诀：“边界（防火墙/WAF）、主机（EDR/HIDS）、网络（IDS/IPS）、身份（堡垒机/MFA）、漏洞（扫描器）、数据（DLP/加密）、日志（SIEM）"。
  • 回答结构：“产品做什么 + 放哪里 + 防什么”。

• 进阶思考

  • EDR 和传统杀毒有什么区别？
    • 杀毒以特征库为主（已知样本比对，对 0day/新型攻击较弱）；EDR 更侧重行为检测（监控进程/文件/网络/注册表行为，发现异常行为即可响应），能更好覆盖未知攻击，且有响应能力（隔离、取证）。现代杀软也融合启发式/ML，趋势是 EDR 演进到 XDR（扩展检测响应）。
  • WAF 和 IPS 有什么区别？
    • WAF 专门防护 Web 应用（HTTP/HTTPS 层，理解应用语义：SQL 注入/XSS/CC），部署在 Web 前；IPS 防护网络/系统层（协议漏洞/攻击特征），部署在网络出口。WAF 是 IPS 在应用层的"专家”。
  • 为什么"安全产品堆得越多越好"是误区？
    • 安全效果 = 产品 × 配置 × 运营。堆产品但没人运营（告警没人看、策略不更新）等于摆设，还可能产生大量误报噪音。最佳实践：以风险为导向，选合适产品 + 专人运营（SOC/安全团队）+ 持续优化。

• 扩展信息

  • 开源安全工具栈（自建）：
    • 防火墙：iptables/nftables、OPNsense/pfSense
    • 主机：OSSEC、Wazuh（HIDS）、ClamAV
    • 网络：Snort、Suricata（IDS/IPS）、Zeek（NTA）
    • WAF：ModSecurity、雷池（SafeLine）
    • 扫描：OpenVAS、Nuclei、Trivy
    • 日志：ELK、Grafana Loki（SIEM 平替）
    • 堡垒机：JumpServer
    • 漏洞情报：NVD、CNVD、CISA KEV
  • 商业产品参考：深信服、奇安信、绿盟、启明星辰、山石（国内）；Palo Alto、Fortinet、CrowdStrike、Splunk（国外）

🤔 如果网站遇到 CC 攻击，该怎么处理？

• CC 攻击（Challenge Collapsar，应用层 DDoS）处置核心是"区分人机 + 限流 + 清洗"：确认攻击特征 → 用验证码/JS 挑战区分人机 → WAF 拦截/限流（频率/行为）→ 应用层缓存/静态化降负载 → 高防清洗 → 事后加固。

  • 第一步：确认是 CC 攻击（识别特征）

    • 大量"看似合法"的请求刷动态接口（登录、搜索、下单、API）
    • 来源 IP 分散（肉鸡）或单 IP 高频；UA 异常（大量相同 UA 或随机 UA）
    • QPS 突增但带宽消耗不大（区别于流量型 DDoS）
    • 请求集中打某些高消耗接口（数据库查询重的）

  • 第二步：区分人机（验证）

    • 验证码：关键接口加验证码（图形/滑块/无感验证）
    • JS 挑战：JS 计算验证（如客户端算 PoW），阻挡无 JS 执行能力的脚本
    • Cookie 挑战：首次访问设置 Cookie 校验，后续放行
    • 通过挑战的才放行，攻击脚本无法通过

  • 第三步：WAF 层防护

    • 频率限制：单 IP/单会话 QPS 限制（Nginx limit_req、WAF 频率策略）
    • 行为分析：WAF/云高防行为分析（同 UA、同路径高频、短时间大量请求）自动拦截
    • IP 信誉：封禁恶意 IP/网段、代理 IP 库识别
    • 人机验证接入：WAF 直接下发验证码/滑块

  • 第四步：应用层优化（降负载）

    • 缓存：动态接口结果缓存（Redis）、页面静态化/CDN 缓存
    • 限流降级：超出阈值返回降级页/排队（熔断保护后端）
    • 异步化：耗时操作异步处理，减轻请求压力
    • 加固数据库：慢查询优化、连接池限制（防打崩数据库）

  • 第五步：高防与恢复

    • 接入云高防（WAF+CC 防护），高防 CDN 隐藏源站
    • 确认业务恢复、持续监控

  • 事后复盘

    • 分析攻击特征（来源、接口、频率）、评估防护效果
    • 常态化限流/防护策略、接口加固、监控告警（QPS 突增）

• 协助记忆

  • CC 处置口诀：“认（识别）、验（人机）、限（频率）、缓（缓存）、防（高防）"。
  • 关键认知：“CC 打的是应用层，防靠人机区分 + 限流 + 缓存，不是带宽”。

• 进阶思考

  • CC 攻击和正常高并发（如秒杀）怎么区分？
    • 区分维度：①请求分布（正常用户随机分散，CC 集中刷目标接口）；②行为模式（正常有交互路径，CC 高度重复、无业务上下文）；③来源（CC 肉鸡 IP 段/代理特征）；④时段（CC 可能 24h 持续，秒杀是短时高峰）。结合业务基线和行为分析（设备指纹、Cookie 连续性）综合判断。
  • 验证码为什么能挡住 CC？攻击者不也能过吗？
    • 验证码（尤其无感/行为验证）能区分"人机”：脚本无法低成本通过。攻击者用人肉打码/训练模型可过，但成本高、效率低，大规模 CC 就不划算。验证码的作用是"提高攻击成本"而非绝对阻断。
  • CC 攻击的"终极防御"是什么？
    • 组合拳：高防（隐藏源站 + 清洗）+ 人机验证 + 业务层限流 + 接口加固 + 监控响应。单靠一个手段都会被绕过；核心是"让攻击者打不动、打不起、打了也白打"（源站不暴露 + 成本高 + 应用扛得住）。

• 扩展信息

  • Nginx 防 CC 常用配置：
    1 2 3 4 5 6

    # 限制单 IP 请求频率 limit_req_zone $binary_remote_addr zone=cc:10m rate=10r/s; server { location / { limit_req zone=cc burst=20 nodelay; } } # 限制单 IP 连接数 limit_conn_zone $binary_remote_addr zone=conn:10m; server { location / { limit_conn conn 50; } }

  • CDN/WAF 防 CC 手段：
    • 云 WAF 频率策略、人机验证、IP 信誉库、CC 防护开关
    • 高防 CDN 的"静态资源缓存 + 动态接口保护"组合

🤔 堡垒机有什么作用？

• 堡垒机（Bastion Host/跳板机，国内常叫运维审计系统）的核心作用是"统一入口 + 权限管控 + 全程审计"：作为运维操作的唯一入口（集中登录管理）、细粒度权限控制（谁能登哪台机器/执行什么）、操作全程录像审计（合规 + 溯源）。

  • 核心功能

    • 统一入口：所有运维操作（SSH/RDP/数据库/Web）经堡垒机接入，杜绝运维直连生产
    • 权限管控：细粒度授权（主机/账号/命令/时间），最小权限、按需授权
    • 操作审计：全程录屏 + 命令记录 + 操作日志，可回放溯源
    • 身份认证：统一认证（账号 + MFA），支持对接 AD/LDAP
    • 密码管理：托管服务器账号密码（免密托管、定期轮换），运维不接触真实密码
    • 审批流：高危操作审批（如生产变更需审批后执行）

  • 解决的痛点

    • 账号管理混乱：一台服务器多人共用一个 root 密码 → 出问题无法定位是谁
    • 操作无审计：违规操作无记录 → 无法追责、不符合等保
    • 权限失控：运维/开发权限过大，无最小权限管控
    • 合规要求：等保 2.0 要求"操作审计、三员分立"，堡垒机是落地工具

  • 工作原理（部署形态）

    • 运维人员 → 登录堡垒机 → 经堡垒机（代理）→ 访问目标服务器
    • 目标服务器只放行堡垒机 IP（白名单），不直接暴露
    • 所有会话被堡垒机录制/审计
    • 部署形态：单机（小规模）/ 集群高可用（大规模）/ 云堡垒机（SaaS）

  • 堡垒机 vs 跳板机

    • 跳板机：简单中转登录（无/少审计）
    • 堡垒机：跳板 + 权限 + 审计 + 密码托管（企业级）

• 协助记忆

  • 堡垒机口诀：“唯一入口（统一登录）、细粒度权限（最小授权）、全程审计（录屏溯源）"。
  • 价值一句话：“让运维操作’看得见、管得住、查得到’"。

• 进阶思考

  • 堡垒机怎么做到"免密托管"又"不泄露密码”？
    • 服务器账号密码由堡垒机加密托管（凭据保险库），运维人员登录时堡垒机代填/代连，运维全程不接触明文密码。这样：①密码不共享（多人共用 root 改为每人独立账号）②密码可定期自动轮换 ③即使运维离职，密码已轮换。
  • 为什么等保/合规要求必须上堡垒机？
    • 等保 2.0 要求（三级及以上）“安全审计”（操作行为记录）、“身份鉴别”（唯一标识）、“访问控制”（最小权限/三员分立）。堡垒机天然满足：统一认证（身份）、权限管控（访问控制）、录屏审计（审计）、托管密码（防越权）。是等保测评的常见标配。
  • 堡垒机自身被攻破怎么办？
    • 堡垒机是"高价值目标”（掌握所有入口和凭据），所以自身要重点防护：高可用部署（防单点）、自身加固（补丁/基线/防火墙）、MFA 强制、堡垒机管理账号独立、访问堡垒机本身也要审计、与生产网络隔离。

• 扩展信息

  • 常见堡垒机产品：
    • 开源：JumpServer（最流行，功能全）、Teleport
    • 商业：齐治、帕拉迪、行云管家、云厂商堡垒机（阿里云/腾讯云）
    • 注意：Citrix（思杰）属远程桌面/VDI 领域（Citrix Gateway/NetScaler），2022 年被 Vista Equity Partners 私有化（非思科收购），不是国内语境下的商业堡垒机，勿混淆
  • 堡垒机支持的主流协议/场景：
    • SSH/RDP（服务器）、数据库（MySQL/PostgreSQL 等）、Web 应用（Web 资产）、K8s（kubectl 审计）、云资源（云主机纳管）

🤔 运维安全基线有哪些内容？

• 运维安全基线是"最低限度的安全配置要求"，覆盖：账号与认证、系统加固、网络与端口、服务与进程、日志与审计、文件权限、数据安全、应急与监控八类（示例性分类，非权威标准分类）。核心原则：最小权限、最小暴露、默认安全、可审计。**

  • 账号与认证基线

    • 账号唯一性：一人一账号（禁用共享 root）
    • 最小权限：按需授权、sudo 白名单、定期审计权限
    • 认证强度：强密码策略（复杂度/长度/有效期）、MFA、禁用弱认证
    • 账号生命周期：入职开通、离职回收、僵尸账号清理

  • 系统加固基线

    • 补丁管理：及时更新、关键漏洞时限修复
    • 内核/系统参数：网络参数加固（禁用 IP 转发/重定向，按需）、内核参数安全
    • SELinux/AppArmor：强制访问控制开启（按业务评估）
    • 系统版本：支持的操作系统版本（停止维护的 OS 不上线）

  • 网络与端口基线

    • 防火墙默认拒绝，只放行业务必需端口
    • 最小暴露面：公网只暴露必需服务（Web/SSH 等），管理口限制来源
    • 网络分段：内外网隔离、业务分区（DMZ/内网）、敏感网段隔离
    • SSH 加固：禁用 root 远程、密钥认证、限制来源

  • 服务与进程基线

    • 最小化服务：只跑业务必需服务，关闭无用服务/组件
    • 禁用不必要的协议/组件（telnet、rsh、共享默认配置）
    • 服务配置安全：去默认口令、去默认配置、最小权限运行（非 root）

  • 日志与审计基线

    • 日志开启：系统/应用/安全日志全量开启
    • 日志留存：保留时长满足合规（等保要求日志留存）
    • 日志集中：集中收集（rsyslog/ELK）+ 异机存储（防被抹）
    • 审计：操作审计（堡垒机）、登录/操作记录

  • 文件权限基线

    • 敏感文件权限：/etc/shadow（600）、/etc/passwd 等收紧
    • 世界可写文件排查、SUID/SGID 文件清单核对
    • umask 安全值（022/027）

  • 数据安全基线

    • 数据加密：传输加密（TLS/VPN）、存储加密（磁盘/数据库）
    • 备份策略：3-2-1 原则、备份加密、恢复演练
    • 数据分级：敏感数据识别与保护（DLP）

  • 应急与监控基线

    • 监控告警：资源/服务/安全监控（异常登录、外连、文件变更）
    • 应急预案：事件分级、响应流程、演练
    • 安全扫描：定期漏洞扫描、基线核查

• 协助记忆

  • 基线八类口诀：“账号、系统、网络、服务、日志、文件、数据、应急”。
  • 核心四原则：“最小权限、最小暴露、默认安全、可审计”。

• 进阶思考

  • 安全基线和安全策略有什么区别？
    • 安全策略（Policy）是"方向性要求"（应该做什么，如"必须防 DDoS"）；安全基线（Baseline）是"具体配置标准"（怎么配，如"SSH 必须密钥认证、防火墙默认拒绝"）。基线是策略的落地细化，是可检查、可量化的清单。
  • 基线如何"可检查"而不只是文档？
    • 用基线核查工具自动检查：CIS-CAT、OpenSCAP、kube-bench（K8s）、云安全中心基线检查；或自建脚本对照基线项逐条核查，生成合规报告。补充：lynis（Linux 安全审计加固）和 Trivy（镜像漏洞扫描）属安全审计工具，可辅助但非严格"合规基线核查"工具。基线 + 工具 + 定期检查，才能持续合规。
  • 基线和新业务上线如何结合？
    • 新业务上线前做"上线安全评审"：对照基线检查，不合规项整改后才能上线（安全门禁）。同时基线要随业务演进持续更新（新服务、新组件纳入）。把安全基线嵌入发布流程（CI/CD 安全检查），是最有效的落地方式。

• 扩展信息

  • 常见基线标准：
    • CIS Benchmarks（各系统/应用行业公认的基线）
    • 等保 2.0（国内合规基线）
    • 各厂商安全加固手册（红帽/微软/华为）
  • 基线核查工具：
    • 合规基线核查：OpenSCAP、CIS-CAT、kube-bench（K8s）、云厂商安全中心（等保自查）
    • 安全审计辅助：lynis（Linux 审计加固）、Trivy（镜像漏洞扫描）
  • 基线落地流程：
    • 定义基线（选标准）→ 工具化检查 → 定期核查 → 违规整改 → 持续更新