Poison Over Forwarders攻击复现报告
Poison Over Forwarders 攻击复现报告一、摘要本报告详细记录了对[USENIX Security 2020]《Poison Over Troubled Forwarders: A Cache Poisoning Attack Targeting DNS Forwarding Devices》中所述攻击的复现过程。该攻击是一种针对 DNS 转发设备的新型缓存投毒技术,它巧妙地利用了IP协议层面的分片与重组机制,从而绕过了传统的、依赖于传输层(如源端口随机化)的DNS安全防御措施。
我们通过 Docker 构建了一个包含易受攻击的 DNS 转发器(dnsmasq)、攻击者控制的权威服务器和攻击者客户端的隔离网络环境。实验中,攻击者首先向转发器注入一个精心构造的、伪造的 IP 第二分片,然后触发一个对攻击者域名的查询,诱使其权威服务器返回一个超大的、会被合法分片的DNS响应(实验复现中采用的是超长CNAME链)。转发器在重组IP包时,错误地将合法的第一个分片与伪造的第二个分片结合,最终导致其 DNS 缓存被植入指向攻击者指定域名(例如victim.cn)的恶意 IP 地址 ...
Poison Over Forwarders攻击评估报告
Poison Over Forwarders评估说明评估脚本获取measure.py源码
1.漏洞说明来源[USENIX Security 2020]Poison Over Troubled Forwarders: A Cache Poisoning Attack Targeting DNS Forwarding Devices
基本原理介绍该漏洞是一种针对DNS转发器的新型缓存投毒攻击。与传统攻击不同,它利用IP分片和由攻击者控制的权威DNS服务器来绕过常见的DNS安全防御机制(如端口随机化、0x20编码等)。
强制分片: 攻击者控制一个权威DNS服务器。当有DNS查询请求时,该服务器通过构造一个包含超长CNAME记录链的DNS响应,必须对该响应进行IP分片
分片注入: 一个被分片的DNS响应包,只有第一个分片包含UDP和DNS头部信息(如事务ID、端口号等)。攻击者利用这一点,在第一个合法分片到达前,向DNS转发器注入伪造的第二个分片
重组缓存: DNS转发器接收到合法的第一个分片和伪造的第二个分片后,会将它们重组。由于伪造的分片篡改了CNAME链的末尾,将其指向了受害者域名( ...
Kaminsky攻击复现报告
kaminsky复现报告一、摘要本报告旨在记录并分析经典的 Kaminsky DNS 缓存投毒攻击的复现过程。我们通过 Docker 构建了一个包含易受攻击的递归DNS服务器、攻击者和合法权威服务器的隔离网络环境。实验中,攻击者通过向递归服务器查询一系列不存在的随机子域名,并抢在合法响应前发送大量伪造的DNS响应包,成功地在其缓存中植入了恶意的 NS 记录。实验结果表明,攻击成功后,所有对目标域名的查询均被重定向至攻击者指定的服务器,直观地验证了 Kaminsky 攻击的巨大危害性。
二、原理分析Kaminsky 攻击的核心并非直接猜测并伪造目标域名(如www.example.com)的 A 记录,而是通过污染其父域(example.com)的权威 NS 记录来获得整个域的解析控制权。其攻击逻辑如下:
攻击者向受害者递归服务器(10.10.0.6)查询一个随机且不存在的子域名,例如 random-string.example.com。由于缓存中没有该记录,递归服务器必须向外查询。
递归服务器会向其配置的根/权威服务器(本例中为被攻击者控制的10.10.0.8)发起请求。攻击者通过让1 ...
Linux主机Headless与Headed无缝热插拔切换
Linux主机物理屏与虚拟屏切换指南书接上文,虽然我们已经实现了Linux主机的虚拟屏设置,可以很好的使用该“无头”服务器,但是如果我们希望给他外接物理显示屏则必须删除虚拟驱动设置,然后再重启。主包觉得这样太过麻烦了,是不是可以让系统自动检测当前是否有显示屏接入,如果接入显示屏那我们采用真实显卡设置,否则采用DUMMY虚拟驱动?
如何启动虚拟屏参见“无头”Linux主机远程桌面使用指南中“使用X11桌面协议”与“配置X.org服务器”
启动虚拟屏进阶对于上篇博文中提到的开机服务,可以设置为用户层面的服务,此时无需指定DISPLAY,这意味着鲁棒性更强vim ~/.config/systemd/user/x11vnc.service
[Unit]Description=x11vnc server for the current graphical sessionAfter=graphical-session.target[Service]ExecStart=/usr/bin/x11vnc \ -remap /home/chi/.x11vnc_remap \ -xkb \ -fore ...
“无头”Linux主机远程桌面使用指南
无显示器使用Linux主机(Ubuntu 24.04.2 LTS)实录前言五一的时候,主包拥有了自己第一台主机(mini版)。因为觉得有ssh控制就已经很满足了,所以并没有察觉到显示屏的重要性。直到卸载Win10安装Ubuntu后,由于联发科网卡反复出现网络问题(吐槽一嘴,Linux的联发科的驱动真的不太行,建议直接换Intel原生态的网卡),导致不得不需要显示屏才能控制主机(故琢磨一天,总结了几种方案)
视频采集卡 + OBS studio(推荐)懒人版,需要有一台可以使用HDMI或者DB线的笔记本电脑(?),总之就是一台宿主机
宿主机安装OBS studio软件,充当主机视频信号载体
主机接HDMI线连接视频采集卡,视频采集卡接入宿主机
OBS studio新增一个视频窗口,初始化部分应该是可以检测到视频采集卡的,然后就大功告成了
大致方案为,找到源,添加视频采集设备,然后按照识别到的视频采集卡设备进行设置,例如我是UGREEN HDMI Capture,其他配置一律默认即可
远程控制软件 + Xorg服务器(不推荐!!!)可能需要借用一个显示屏配置一下ToDesk()
安 ...
机器学习复习
ML 期末突击方差与偏差靶心与飞镖:一个绝佳的比喻想象一下你正在玩射飞镖,目标是靶心(Bullseye)。靶心就是我们想要预测的真实值。你射出的每一支飞镖,都是一次模型的预测。
我们用不同的训练数据子集训练出的不同模型,就像你一次次地投掷飞镖。
低偏差,低方差 (Low Bias, Low Variance) - 理想情况
表现:所有的飞镖都紧密地集中在靶心周围。
解读:模型既准确(低偏差)又稳定(低方差)。每次训练出的模型都能准确预测。这是我们的终极目标。
高偏差,低方差 (High Bias, Low Variance) - 欠拟合
表现:所有的飞镖都紧密地聚集在一起,但离靶心很远。
解读:模型很稳定,每次预测的结果都差不多(低方差),但它系统性地出错了,离真实值很远(高偏差)。模型太简单了,比如用一条直线去拟合一个二次曲线的数据。
低偏差,高方差 (Low Bias, High Variance) - 过拟合
表现:飞镖围绕着靶心散布得很开,没有聚集在一起。
解读:平均来看,预测是围绕真实值的(低偏差),但每次预测的结果都非常不稳定(高方差)。模型学到了太多训练数 ...
OS挑战性任务
lab6-challenge shell要求总览
相对路径支持
环境变量管理
指令输入优化
无后缀指令支持
终端输入输出优化
历史指令支持
实现更多功能
追加重定向功能
注释功能
变量替换
反引号执行功能
指令条件执行功能
实现更多指令
内建指令篇
history
cd
pwd
exit
declare
unset
正常指令篇
ls
rm
touch
mkdir
1.相对路径支持首先需要实现工作目录,为每个进程加入属性env_cwd,并在env_alloc/sys_exofork时使得子进程继承父进程的工作目录struct Env { //... char env_cwd[MAXPATHLEN]; //...}// env_allocstrcpy(e->env_cwd, "/");// sys_exoforkstrcpy(e->env_cwd, curenv->env_cwd);
实现辅助函数normalize_path,协助转换为绝对路径,该函数支持传入路径相对或绝对
对于相对路径,将 ...
OS理论复习
OS_RElec1 Introductionlec2 Bootlec3 Memory Managementlec4 Process/Thread进程与线程并发
若干个程序同时在系统中运行,这些程序在执行的时间上是重叠的
并行
多个程序,它们在同一时间度量下同时运行在不同的处理机上,则称两个程序是并行执行的
并行则一定并发,而并发不一定并行。因为并发只是在宏观维度下两个程序在执行时间上是重叠的,在这期间,它们可能是运行在同一处理机的不同时间段,,也可能运行在完全不同的处理机上。并行则要求两个程序运行在完全不同的处理机上。
竞争
多个程序读写同一个共享数据的结果依赖于它们的执行顺序
进程进程的定义
进程是对CPU资源的一种抽象
进程与程序不同。进程可以简单理解为程序运行的过程。同时其是系统进行资源分配与调度(线程发明前)的基本单位
进程包含程序、数据、进程控制块
进程的控制
就绪状态:进程获取除处理机外所有所需资源,等待分配处理机资源
执行状态:占用处理机资源。处于此状态下的进程数小于等于CPU数目
阻塞状态:正在执行的进程,由于发生某种事件而暂时无法执行,便放弃了处理机 ...
面向对象u2
oo_u2总结第二单元终于结束力,电梯月结束了!!!
第一次作业
薛定谔的电梯
第一次的电梯总是轻松愉快的,乘客指定了需要某部电梯来接送,这意味着我们不需要调度电梯,只需要关注电梯的运行。当然,今年较往年增加了乘客优先级的概念,最后性能分的计算中平均等待时间进化为加权平均等待时间。
整体思路
架构设计整体电梯系统依然采用生产者-消费者模型。主输入线程InputThread作为生产者,负责“生成”乘客请求,这里更准确地来说是“接收”我们输入的乘客请求,但是从电梯系统来看,乘客都是主输入线程产生的;电梯线程ElevatorThread作为消费者,负责“清理”乘客请求,也就是将乘客送到目的地;分配器线程DispatchThread作为盘子,接收主输入线程的乘客,同时可供电梯线程获取。不过与传统的生产者-消费者模型相比,我们需要分配器主动分配乘客请求给电梯线程,而不是等待电梯线程来获取。
这是考虑到电梯线程的逻辑复杂。一般的消费者线程只需要简单处理即可继续获取,但对于电梯线程而言,什么时候意味着处理完毕可以继续获取乘客请求?难道是等电梯运送完目前得到的所有乘客请求吗?这无疑会导致电梯错过携 ...