实训学习Day 2 网络攻击溯源与流量分析

声明：本博客仅用于学习交流记录

目录

实训目的

实训准备及注意事项

实训背景知识

实训任务1 SYN半链接攻击流量分析

实验任务2 SQL注入攻击流量分析一

实验任务3 SQL注入攻击流量分析二

实验任务4 Web入侵溯源一

实验任务5 Web入侵溯源二

---

• 实训目的

• 了解拒绝服务攻击Dos和分布式拒绝服务攻击DDos原理。
• 了解Web入侵的一般步骤。
• 能进行拒绝服务攻击的流量分析。
• 能进行Web入侵的溯源分析。

• 实训准备及注意事项

• 1．硬件：装有Windows操作系统的计算机1台。
• 2．软件：wirshark、网络攻击数据包(安恒平台)。  
• 3．严格按照实验步骤进行实验，实验结果以截图的形式进行保留。

• 实训背景知识

• 拒绝服务攻击即是攻击者想办法让目标机器停止提供服务，是黑客常用的攻击手段之一。其实对网络带宽进行的消耗性攻击只是拒绝服务攻击的一小部分，只要能够对目标造成麻烦，使某些服务被暂停甚至主机死机，都属于拒绝服务攻击。拒绝服务攻击问题也一直得不到合理的解决，究其原因是因为网络协议本身的安全缺陷，从而拒绝服务攻击也成为了攻击者的终极手法。攻击者进行拒绝服务攻击，实际上让服务器实现两种效果：一是迫使服务器的缓冲区满，不接收新的请求；二是使用IP欺骗，迫使服务器把非法用户的连接复位，影响合法用户的连接。
• SYN Flood是当前最流行的DoS（拒绝服务攻击）与DDoS（Distributed Denial Of Service分布式拒绝服务攻击）的方式之一，这是一种利用TCP协议缺陷，发送大量伪造的TCP连接请求，使被攻击方资源耗尽（CPU满负荷或内存不足）的攻击方式。具体原理是：TCP连接的三次握手中，假设一个用户向服务器发送了SYN报文后突然死机或掉线，那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的（第三次握手无法完成），这种情况下服务器端一般会重试（再次发送SYN+ACK给客户端）并等待一段时间后丢弃这个未完成的连接。这段时间的长度我们称为SYN Timeout，一般来说这个时间是分钟的数量级（大约为30秒-2分钟）；一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题，但如果有一个恶意的攻击者大量模拟这种情况（伪造IP地址），那么服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源。即使是简单的保存并遍历也会消耗非常多的CPU时间和内存，何况还要不断对这个列表中的IP进行SYN+ACK的重试。实际上，如果服务器的TC P/IP栈不够强大，那么最后的结果往往是堆栈溢出崩溃——即使服务器端的系统足够强大，服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求（毕竟客户端的正常请求比率非常之小），此时，从正常客户的角度看来，服务器失去响应，这种情况就称做：服务器端受到了SYN Flood攻击（SYN洪水攻击）。

• 实训任务1 SYN半链接攻击流量分析

• 使用 wireshark 打开 nmap.pcap 文件。
• 
• 打开数据包之后，发现大量来自 192.168.177.155 的 TCP 连接请求，且均为 TCP 三次握手中的第一次 SYN 请求，而且目的端口一直在改变。
• 
• 观察数据包，当服务端进行进行第二次握手之后，客户端并没有响应。
• 
• 由此可以判断出，此时 192.168.177.155 这台主机正在对 192.168.177.145 这台主机进行端口扫描。而且扫描模式为 SYN 半连接扫描。     注：SYN 半连接扫描使用含有 SYN 标志位的数据包进行端口探测。如果目标主机回复了SYN/ACK包，则说明该端口处于开放状态。如果回复的是 RST/ACK 包，则说明这个端口处于关闭状态；
• 基于 SYN 半连接扫描的特点，我们可以通过显示过滤器过滤出 192.168.177.145 回复了SYN/ACK 的数据包。以确定 192.168.177.145 开放了哪些端口。
• 
• 经分析可知，192.168.177.145 这台机器一共回复了 15 个 SYN/ACK 数据包。所以可以判断出，这台机器一共开放了 15 个端口。且分别为红框中的 15 个端口。

• 实验任务2 SQL注入攻击流量分析一

• 使用 wireshark 打开提供的 web.pcap 数据包。
• 
• 因为要分析针对 web 的攻击。所以在显示过滤器中输入 http 过滤出 http 协议相关的数据包。
• 查看 http 数据包的 get 请求参数处，发现大量的 sql 语句。我们可以判断，黑客正在对目标进行 sql 注入攻击。
• 
• 通过 get 请求的来源 IP，可以判断出黑客的 IP 为 192.168.177.1。
• 
• 观察 get 请求包的 user-agent 头为 python-reqursts，可以判断黑客使用了 python 脚本对目标实施的攻击。同时攻击的 payload 中 ascii，和比较符等关键字。说明黑客使用的注入技术为布尔盲注。
• 
• 观察数据包 get 请求的参数，根据黑客提交的 payload，if(length(database()=0,1,0))，其中 length 是获取 database()的数据库名的长度。然后通过 0,1,2 等进行比较，当相等时，返回 1。这使得 ‘1’and 1 为真，有查询结果返回。所以通过这个 payload，我们可以得出，黑客此时是在判断数据库名的长度。
• 
• 分别观察前 9 条请求的响应数据包。通过响应包内容可以发现，前 8 条请求的响应包内容相同，而第 9 条的响应包内容不同。根据 payload 的内容我们可以判断出黑客已经获得了数据库名的长度为 8。
• 
• 

• 在看第 9 条请求包之后的数据包，分析黑客提交的 payload，1'and%20if(ascii(substr(database(),1,1))=79,1,0)%20--+通过 substr 函数，将 database()函数的值，从第一位开始，截取一位，然后在转化为 ascii码跟 79 进行比较。如果数据库名称的第一位值的 ascii 码值等于 79，则会返回 1，否则返回0，这样当返回 1 时，’1’and 1 为 true，即可正常查询到数据。通过依次截取第一位，第二位，第三位等，这么就能获得数据名每一位的值，依次拼接之后，即可获得完整的数据库名。根据黑客提交的 payload 的含义，我们可以得出，黑客此时是在逐位获取数据库名称。
• 
• 根据黑客测试的 payload 的回显示信息来判断，可得到当响应包中出现 You are in……的时候为查询正常。所以我们可以判断出数据库第一位的 ascii 码值为 115。对应的值为 s。
• 
• 根据第 9 步的判断方法。依次判断后面的数据包，可得知，黑客获取数据库 8 位的全部字符。得到了数据库名称。最终数据库的名称为 security。
• 
• 根据数据到的分析，我们可知最终黑客只获取了数据库名的长度和数据库名称。

• 实验任务3 SQL注入攻击流量分析二

• 使用 wireshark 打开提供的 web.pcap 数据包。
• 
• 因为要分析针对 web 的攻击。所以在显示过滤器中输入 http 过滤出 http 协议相关的数据包。
• 
• 查看 http 数据包的 get 请求参数处，发现大量的 sql 语句。我们可以判断，黑客正在对目标进行 sql 注入攻击。且来源 IP 为 192.168.177.1。
• 
• 当继续向下浏览数据包时，我们发现出现了大量的来自 192.168.177.145 的 IP，在步骤三时，已经判断出，来源 IP 为 192.168.177.1 正在对网站进行 sql 注入攻击，所以此时我们需要排除192.168.177.145 这个 IP 对的干扰，筛选出所有来源 IP 和目的 IP 为 192.168.177.1 的 http 请求。
• 
• 
• 观察 get 请求包的 user-agent 头为 python-reqursts，可以判断黑客使用了 python 脚本对目标实施的攻击。同时攻击的 payload 中具有 sleep()关键字。说明黑客使用的注入技术为时间盲注。
• 
• 观察数据包 get 请求的参数，根据黑客提交的 payload，if(length(database())=8,sleep(5),0)，其中通过 length函数来获取数据库的长度，然后跟 1-8 的数字进行比较，如果相同则，if 函数执行 sleep(5)。此时就请求包和响应包就会有一个明显的时间差。根据这个特点，我们可以得知，黑客获取了数据库长度为 8。
• 
• 观察之后的 payload，通过 substring 函数截取数据库名的每一位，跟 26 个字母进行比较，如果相等，则会执行sleep()函数，请求包和响应包的时间会出现一个明显的差值。根据这个特点，分析之后的数据包。我们可以判断黑客得到了数据库的名称为 security。
• 
• 

• 实验任务4 Web入侵溯源一

• 使用 Wireshark 打开 webattack.pcap 数据包。
• 
• 因为是对 web 攻击进行溯源分析，所以我们只需要关注 http 协议的数据包。所以在显示过滤器中输入 http，过滤出 http 协议的数据包。
• 
• 从过滤出的数据包中，我们从请求方式和请求参数上来看属于正常浏览的数据包。
• 
• 从数据包编号为 345 的数据包开始，之后出现了大量的 head 请求，以及大量的 404 响应。且来源 IP 都为同一个 IP，由此我们可以判断出，192.168.177.1 这个 IP 在对网站进行目录爆破。
• 
• 从编号为 20553 的数据包开始收到大量的 POST 请求，POST 请求地址都为 admim/login.php 猜测黑客已经通过目录扫描找到了后台登录的路径。
• 
• 在任意一个 POST 数据包上，右键选择追踪流->http 流，查看 http 请求和响应的具体内容。从请求中，我们看到，黑客以 admin 为用户名进行爆破。追踪多个 POST 数据数据包的 http流。发现请求的内容只有 admin_pwd 在变化，admin_name 不变所以可以断定黑客在爆破 admin的密码。
• 
• 从 55019 个数据包开始，开始出现浏览后台文件的 get 请求，此处说明黑客在上一步爆破用户名密码时已经成功获取到了后台的 admin 账户的密码。成功登陆了后台，并开始浏览后台的相关功能。找寻下一步的利用点。
• 
• 在 55500 个数据包这里，开始出现目录遍历的操作。
• 
• 分别追踪这三个数据包的 http 流，前两个数据包的响应包内容均为 JS 代码的返回上一步操作。而第三个数据包的响应包内容为 index.php 的源代码。由此能判断出，黑客通过tpl_manage.php 读取到了 index.php 的源代码。
• 
• 之后 tpl_manage 页面有一个 POST 请求，追踪该请求的 http 流，观察提交的内容和响应的内容。
• 
• 请求体中的内容经过了 URL 编码不利于观察，将其复制到 notepad++ 中进行 URL 解码后观察。
• 
• 
• 在之后的数据包中看到黑客之后又访问了 index.php 页面。而且是 post 请求。结合前一步得出的结论，黑客在 index.php 页面插入了一句话木马之后，这里有可能是黑客对一句话木马进行测试。同样追踪该数据包的 http 流，查看请求和响应的内容。
• 
• 通过追踪 http 流，看到黑客向 index 页面的一句话传递了 phpinfo 函数，响应体的内容也证明了 phpinfo 函数被正确执行。由此确认了一句话写入成功。
• 
• 到此结合此前的分析，可以得出黑客攻击路径的溯源。
  • 首先，黑客通过目录扫描，获取了后台管理地址。
  • 然后通过弱口令爆破，获取到了 admin 账户的密码，登录了后台。
  • 在对后台功能进行一番探索之后，找到了 admin/tpl_manage.php 文件可以通过目录遍历查看并修改任意文件的内容。由此通过修改 index.php 的内容，插入了 php 一句话木马。
  • 之后向 index 页面的一句话木马传递 phpinfo() 确认了一句话写入成功。

• 实验任务5 Web入侵溯源二

• 使用 Wirshark 打开 webattack2.pcap 数据包。
• 
• 因为是对 web 攻击进行溯源分析 ，所以我们只需要关注 http 协议的数据包 。所以在显示过滤器中输入 http 过滤出 http 协议的数据包。
• 
• 通过对数据包的观察，前面部分的数据包为正常访问的数据包。
• 
• 从数据包编号为 1544 的包开始，开始出现 head 请求，以及大量的 404 响应。且访问 IP 都为 192.168.177.1。此时 192.168.177.1 的 IP 正在对网站进行目录爆破。
• 
• 从 37933 个数据包开始，出现对 /dede/login.php 的访问记录。因为 dede 为 dedecms 的默认后台地址。此时黑客可能已经获取到了后台路径，且开始尝试登陆。
• 
• 查看 POST 数据包的内容，发现提交内容的用户名为 admin，密码为 123456 等弱口令，猜测黑客此时在进行弱口令测试。
• 
• 发现在 38164 个数据包时，出现了 index.php 的访问记录，观察前一个数据包的返回内容，其返回的内容为 JS 跳转，跳转到 index 页面，猜测此时黑客可能已经登录成功，且登录的用户名和口令为 admin/admin。
• 
• 
• 
• 之后黑客访问了 dede/ad_add.php 这个页面，dedecms 在 5.7 版本，这个页面存在 getshell漏洞，黑客应该是想利用此漏洞来进行 getshell。查看黑客此次 POST 提交的内容。发现了一句话木马。可以证实黑客是进行了 getshell 的操作。
• 
• 
• 之后出现了大量的对 ad_js.php 页面的 POST 请求，查看请求的内容，为 php 代码。此时黑客可能已经成功 getshell，使用菜刀工具对 webshell 进行了连接。
• 
•