红蓝对抗之蓝队面试题part 3

本文已参与「新人创作礼」活动，一起开启掘金创作之路

SQL注入检测

SQL注入攻击检测可根据入侵事件发生的前后进行区分，在入侵前可以对 Payload 进行检测等方式以预防 SQL 注入攻击。在入侵检测后可以通过对数据库、IIS 日志等进行检查以进行判断

传统的SQL注入检测方法通常根据经验提取特征，然后基于规则库匹配的方法来检测是否为 SQL 注入语句，其设计一般较为复杂，且规则模式更新频繁，在此采用机器学习的方式尝试对 SQL 注入语句进行检测

DDOS CC应急思路以及如何防范

目前对于低网络层的 DDoS 攻击有一些有效的防护手段，如丢弃第一次 SYN 包，上流量防护设备，上 WAF 封禁地址等

比较难缠的是第七层，第八层的 CC 攻击，它会找到目标网站上比较消耗资源的关键位置，重复发起攻击以消耗 CPU/内存/数据库/IO 等资源，目前的应付手段有：

1. 优化资源消耗高位置的代码
2. 增加硬件设备
3. 上云
4. 购买专业安全公司的安全服务
5. 除此之外，隐藏服务器的真实 IP、上云 WAF、CDN、 负载均衡等设备，或者暂时将域名解析到公安网警网站等也是可以作为选择方案

• 网络设备设施
  • 拼带宽，加大带宽，但是成本太高
  • 使用硬件防火墙
  • 选用高性能设备
• 抗 D 思想和方案
  • 负载均衡
  • 花钱买流量清洗服务
  • CDN：web 层，比如 cc 攻击
  • 分布式集群防御
  • 高防：防大部分攻击，udp、大型的 cc 攻击
• 预防为主
  • 系统漏洞
  • 系统资源优化
  • 过滤不必要的服务和端口
  • 限制特定流量：检查访问来源做适当限制

挖矿病毒判断&挖矿常见手段&处理

挖矿病毒，自己搜搜

挖矿木马占用系统资源进行挖矿行为，一般电脑会有以下特征

1. 系统响应缓慢
2. CPU/显卡使用率过高
3. 内存/带宽占用高

登录进可疑主机后，可以通过以下方式确认挖矿木马（即入侵排查流程）

1. 查看进程（系统命令 ps、Is 有可能被替换）
2. 检查日志、检查系统用户
3. 发现异常文件

挖矿常用手段

1. 未授权访问或弱口令：Redis 未授权访问、Docker API 未授权访问、Hadoop Yarn 未授权访问、NFS 未授权访问、Rsync 弱口令、PostgreSQL 弱口令、Tomcat 弱口令、SSH 弱口令、Telnet 弱口令、Windows 远程桌面弱口令
2. 远程命令执行漏洞：WebLogic XML 反序列化漏洞、Jenkins 反序列化、Jboss 远程代码执行、Spring 远程代码执行、ElasticSearch 命令执行、永恒之蓝、Struts2 系列漏洞、常见 CMS 的远程命令执行漏洞
3. 新爆的高危漏洞：一般每次爆发新的高危漏洞，都会紧跟一波大规模的全网扫描利用和挖矿

清除挖矿木马

原因排查

一旦发现服务器被挖矿，应该首先查看挖矿进程所属的用户，根据挖矿进程的运行用户去排查该用户下是否还运行着其它进程，确定这些进程是否有上述经常被黑客利用的漏洞。如果有常见的漏洞，则应该重点对此进行排查找到原因

清除木马

1. 及时隔离主机

   部分带有蠕虫功能的挖矿木马在取得本机的控制权后，会以本机为跳板机，对同一局域网内的其他主机进行已知漏洞的扫描和进一步利用， 所以发现挖矿现象后，在不影响业务的前提下应该及时隔离受感染主机，然后进行下一步分析

2. 删除文件、阻断与矿池通讯

   iptables -A INPUT -S xmr.crypto- pool.fr -j DROP
   iptables -A OUTPUT -d xmr.crypto- pool.fr -j DROP
   

3. kill 挖矿进程

   对于单进程挖矿程序，直接结束挖矿进程即可。但是对于大多数的挖矿进程，如果挖矿进程有守护进程，应先杀死守护进程再杀死挖矿进程，避免清除不彻底 在实际的清除工作中，应找到本机上运行的挖矿脚本，根据脚本的执行流程确定木马的驻留方式， 并按照顺序进行清除， 避免清除不彻底

4. 清除定时任务

   大部分挖矿进程会在受感染主机中写入定时任务来完成程序的驻留，当安全人员只清除挖矿木马时，定时任务会再次从服务器下载挖矿进程或者直接执行挖矿脚本，导致挖矿进程清除失败

5. 清除启动项

   有的挖矿进程为了实现长期驻留，会向系统中添加启动项来确保系统重启后挖矿进程还能重新启动，所以在清除时还应该关注启动项中的内容如果有可疑的启动项，也应该进行排查，确认是挖矿进程后，对其进行清除

6. 清除公钥文件

   在用户 home 目录的 .ssh 目录下放置 authoruzed_keys 文件，从而免密登录该机器也是一种常见的保持服务器控制权的手段。在排查过程中应该查看该文件中是否有可疑公钥信息，有的话直接删除，避免攻击者再次免密登录该主机

服务器存在webshell，如何处理？

网站被植入 webshell，意味着网站存在可利用的高危漏洞，攻击者通过利用漏洞入侵网站，写入 webshell 接管网站的控制权

1. 及时隔离主机
2. 定位事件范围，查看文件 webshell 文件的创建时间，对 webshell 取证样本
3. 通过创建时间结合日志分析可疑行为，以及启动用户的其他进程确定漏洞
4. 清除 webshell 及残留文件，修复漏洞，参考上题

排查 shell 应该用什么命令来进行排查

find 命令

find /var/www/html -name "*.php" |xargs egrep 'assert|eval|phpinfo\(\)|\(base64_decoolcode|shell_exec|passthru|file_put_contents\(\.\*\$|base64_decode\('

如何检测webshell

主机层面

• 静态检测

  静态检测通过匹配特征码，特征值，危险函数函数来查找 webshell 的方法，只能查找已知的 webshell

• 动态检测

  webshell 传到服务器了，在执行函数时这些对于系统调用、系统配置、数据库、文件的操作动作都是可以作为判断依据

• 日志检测

  使用 webshell 一般不会在系统日志中留下记录，但是会在网站的 web 日志中留下 webshell 页面的访问数据和数据提交记录

• 语法检测

  语法语义分析形式，是根据 php 语言扫描编译的实现方式，进行剥离代码、注释，分析变量、函数、字符串、语言结构的分析方式，来实现关键危险函数的捕捉方式这样可以完美解决漏报的情况但误报上

流量层面

Webshell管理工具的流量特征

冰蝎动态二进制加密WebShell特征分析

常见WebShell客户端的流量特征及检测思路

菜刀

菜刀 webshell 只使用了 url 编码 + base64 编码

shell 特征就是传输参数名为 z0，还存在int_set("display_erros","0")字符串特征

蚁剑

默认的蚁剑 shell，连接时会请求两次，其请求体只是经过 url 编码，其流量中也存在和蚁剑一样的代码

第一次请求，关闭报错和 magic_quotes，接下来去获取主机的信息

第二次请求，会把主机目录列出来

冰蝎2.0

使用 aes 加密发起三次请求

第一次请求服务端产生密钥写入 session，session 和当前会话绑定，不同的客户端的密钥也是不同的

第二次请求是为了获取 key，第三次使用 key 的 aes 加密进行通信

冰蝎3.0

使用 aes 加密发起两次请求

3.0 分析流量发现相比 2.0 少了动态密钥的获取的请求，不再使用随机生成 key，改为取连接密码的 md5 加密值的前 16 位作为密钥

一次请求为判断是否可以建立连接，少了俩次 get 获取冰蝎动态密钥的行为，第二次发送 phpinfo 等代码执行，获取网站的信息

哥斯拉

支持 n 种加密

采用了和冰蝎 3.0 一样的密钥交换方式，哥斯拉建立连接时会发起三次请求，第一次请求数据超级长，建立 session，第二三次请求确认连接

常见端口漏洞

数据库类（扫描弱口令）

• 1433：MSSQL
• 1521：Oracle
• 3306：Mysql
• 5432：PostgreSQL

特殊服务类（未授权/命令执行）

• 443：ssl 心脏滴血
• 873：Rsync 未授权
• 5984：CouchDB http：//xxx:5984/_utils/
• 6379：Redis 未授权
• 7001、7002：Weblogic 默认弱口令
• 8088：Hadoop Yarn 资源管理系统 REST API 存在未授权
• 8161：Apache ActiveMQ 未授权、弱口令，put 文件上传，move 文件移动
• 9200、9300：elasticsearch 命令执行
• 11211：Memcache 未授权，telnet ip 就可以获得服务器敏感信息
• 27017、27018：Mongodb 未授权
• 50000：SAP 命令执行
• 50070、50030 Hadoop 未授权访问

常用端口类（弱口令/端口爆破）

• 21：FTP 弱口令，匿名 anonymous/空登录，以及 ms12-073
• 25：SMTP 简单邮件传输服务器端口
• 23：Telnet 的端口，Telnet 是一种可以远程登录并管理远程机器的服务
• 22：ssh 端口，PcAnywhere 建立 TCP 和这一端口的连接可能是为了寻找 ssh，这一服务有许多弱点
• 53：dns 端口
• 139：属于 TCP 协议，是为 NetBIOS Session Service 提供的，主要提供 Windows 文件和打印机共享以及 Unix 中的 Samba 服务
• 445：网络共享 smb 服务，尝试利用 ms08067，ms17010 等以及 IPC$ 攻击手段
• 2601、2604：zebra 路由，默认密码 zebra
• 389：LDAP 未授权访问（通过LdapBrowser工具直接连入）

三次握手与四次挥手

www.eet-china.com/mp/a44399.h…

背景：TCP 位于传输层，作用是提供可靠的字节流服务，为了准确无误地将数据送达目的地，TCP 协议采纳三次握手四次挥手策略

三次握手（three-way handshaking）

TCP 三次握手，其实就是 TCP 应用在发送数据前，通过 TCP 协议跟通信对方协商好连接信息，建立起 TCP 的连接关系

1. 第一次握手：客户端发送 SYN 报文，并进入 SYN_SENT 状态，等待服务器的确认
2. 第二次握手：服务器收到 SYN 报文，需要给客户端发送 ACK 确认报文，同时服务器也要向客户端发送一个 SYN 报文，所以也就是向客户端发送 SYN + ACK 报文，此时服务器进入 SYN_RCVD 状态
3. 第三次握手：客户端收到 SYN + ACK 报文，向服务器发送确认包，客户端进入 ESTABLISHED 状态。待服务器收到客户端发送的 ACK 包也会进入 ESTABLISHED 状态，完成三次握手

四次挥手（Four-Way-Wavehand）

当我们的应用程序不需要数据通信了，就会发起断开 TCP 连接。建立一个连接需要三次握手，而终止一个连接需要经过四次挥手

1. 第一次挥手：客户端发送一个 FIN，用来关闭客户端到服务端的数据传送，客户端进入 FIN_WAIT_1 状态
2. 第二次挥手：服务端收到 FIN 后，发送一个 ACK 给客户端，确认序号为收到序号 +1（与SYN相同，一个FIN占用一个序号），服务端进入 CLOSE_WAIT 状态
3. 第三次挥手：服务端发送一个 FIN，用来关闭服务端到 客户端的数据传送，服务端进入 LAST_ACK 状态
4. 第四次挥手：客户端收到 FIN 后，客户端进入 TIME_WAIT 状态，接着发送一个 ACK 给服务端，确认序号为收到序号 +1，服务端进入 CLOSED 状态，完成四次挥手

一个大范围影响的0day被曝光，作为甲方安全工程师，应该如何处理(★★)

1. 首先是评估 0day 对自身系统的影响（这部分评估需要根据漏洞利用的利用点、是否需要交互、是否会影响系统的 CIA，是否有在野利用 poc，影响资产是否暴露在公网等很多因素决定，详情可以参考 CVSS ）
2. 如果确定有影响的话且有 poc，第一件事是先分析 poc 执行后会在什么地方留下痕迹，我们有什么样的设备去采集这些痕迹所留下的数据，比如说 ntlm relay 这种，可以考虑从 Windows 事件日志当中 event_id 等于 4769 的事件入手编写对应的规则，这样的话可以利用 SIEM 或者实时日志分析平台跑起来，可以建立起初步的感知防线，后期触发告警，人肉运营也可以快速止损
3. 日常建立完整的纵深防御体系，不要依赖于某一道防线

服务器操作系统的安全防范？

1. 停止运行不需要的软件（很可能成为外部攻击的入口）
2. 定期实施漏洞防范措施（选定软件时确认软件的升级状况，确定打补丁方式，关注各种漏洞信息，确认漏洞后调查补丁状况以及防范对策，并制定对应计划）
3. 对不需要对外公开的端口或者服务加以访问限制（通过端口扫描确认各端口服务状态）
4. 提高认证强度

怎么发现有没有被攻击

攻击判断可以建立在设备的基础上，利用设备的告警，如果没有设备的话可以参考以下

网站被攻击：网站被跳转到赌博网站，网站首页被篡改，百度快照被改，网站被植入 webshell 脚本木马，网站被 DDOS、CC 压力攻击

服务器被黑：服务器系统中木马病毒，服务器管理员账号密码被改，服务器被攻击者远程控制，服务器的带宽向外发包，服务器被流量攻击，ARP攻击（目前这种比较少了，现在都是基于阿里云，百度云，腾讯云等云服务器）

对登录记录、系统日志、web 日志等进行分析