分类 kali 下的文章 - 一个CTFer的小窝
首页
状态
友链
留言
追番
更多
视频
搜 索
1
Docker常用命令
56 阅读
2
Jet全家桶和Navicat激活(仅可用于学生学习使用)
43 阅读
3
CTF show web入门之文件上传
39 阅读
4
华为交换机&路由器命令
37 阅读
5
软考基本知识
33 阅读
CTF
SQL注入
文件漏洞
PHP特性
命令执行
云存储
云网络
Linux
kali
OpenWrt
登录
搜 索
标签搜索
MySQL
数据库
DNS
根服务器
根节点
软件
激活
HVV
云安全
网络安全
W1lsp0
累计撰写
24
篇文章
累计收到
2
条评论
首页
栏目
CTF
SQL注入
文件漏洞
PHP特性
命令执行
云存储
云网络
Linux
kali
OpenWrt
页面
状态
友链
留言
追番
视频
用户登录
登录
找到
6
篇与
kali
相关的结果
2024-03-24
在DNS中,国际互联网与国内网络有没有互通
@木村·星辰的观点是和根服务器(及镜像污染)有关,国际互联网不再信任中国的 DNS 服务器。但这个说法实际上是很荒谬的,也可以通过实验快速验证。本回答就旨在说明这一问题。 首先从DNS的解析过程入手。不考虑 DNSSEC 等因素,仅讨论最简单的情况,一个典型的解析过程如下:用户请求本地 DNS,本地 DNS 从根开始一步步解析,其中每一步都是获取 NS 记录 和 A(或者 AAAA)记录,最终查询到用户请求的记录。 根服务器中存储了什么?存储了各个 TLD 的 NS 记录和 A/AAAA 记录。具体的记录由 ICANN 旗下的 IANA 保管,内容见 Root Files。全世界所有的根服务器及其镜像的内容都是一致的。 .cn的信息也不例外。在任何一个根服务器的 中,都可以查询到 .cn 正确的 delegation 信息。这一结论可以通过 'dig cn NS 任意一个根' 来快速验证。那么,只要授权 DNS 工作正常,没有理由认为 .cn 会被整个屏蔽。 历史上有没有发生过整个 TLD 被屏蔽的事件?有。早年间曾经发生过伊拉克的 .iq TLD 被整个从根服务器中删除的例子。然而这个例子在今天不适用:.cn 仍在根服务器中活得好好的。 说到底,互联网是一个分布式的系统,“国际互联网”本身就是一个伪概念。互联网有许多组成部分,哪些部分是“国际互联网”呢?事实上,并没有一个部分能完全担得起这个概念。因此,“不被国际互联网信任”本身从逻辑上就无法成立。 我们可以试想一下,假如“[国际互联网]”中的某个部分想屏蔽 .cn 该怎么做。某个运营商可以控制旗下的 DNS,拒绝解析 .cn。或者某个国家的政府可以如此规定。然而,这种做法终究只是某个或某些特定运营商的,很难具有普遍性,更不可能扩散到整个”国际互联网“。 如果上述分析还不足以令人信服,我们通过实验来核实一下就行了。实验利用 RIPE Atlas,这是一个包含了成千上万的家宽、商宽、服务器甚至是卫星连接的巨大监控网络,而我恰好有节点在其中,有资源可以发起全球规模的测试。话不多说,直接上测试结果:Atlas Console 上面的链接无需登录就能打开。测试目标是新华网。新华网的 DNS 全部位于境内。测试节点选用了全世界内 1000 个随机节点(但只有 994 个实际参与)。这个样本量已经足够大了。结果表明,绝大多数的测试节点都能够正常完成解析,而剩下不能完成解析的节点中很有可能也是因网络延迟问题(因为众所周知的原因,跨境网络连接不佳)。至少,绝对不存在 @木村·星辰所说的”国际互联网不信任中国 DNS“这件事。以上,如有不严谨之处欢迎评论区指点。行了,前几天的评论又给我吞了,今天才发现。原样贴过来算了。纯技术问题知乎怎么还吞评论这么严重的。本来是回复@木村·星辰的。 经过查询,我确认了 .cn的确有两个授权 DNS 在境外,不知是不是就是你所说的“镜像”。30s 这个限制实际上是有些不合理的。不考虑缓存因素,当 DNS 记录被修改时(增删改都算),master 会通知 slave 变更,slave 则会在收到通知后发起 AXFR。这个过程即使不考虑众所周知的那个因素,也常常需要一定时间来完成。例如,HE 运营的免费 slave 就常常需要数分钟时间来响应更新请求。可以认为,DNS 记录的更新本就不是实时的,是需要一定时间传播的。不考虑缓存的情况下,存在数十秒延迟是很正常的事,并不能认为是被“阻断”了。实际上我也完成了一项小测试,使用我自己的 .cn 域名测试了伦敦的授权 DNS 的反应速度。我采用了设置 Glue Record 的方法,经过我的测试,设置完成后 20 秒之内信息就同步了,至少我的实验无法支持“境外镜像包含错误信息”这一结论。至于 8.8.8.8 怎么选取 .cn 的授权 DNS,这个我没有找到互联网上的公开信息。如果你有更多信息的话也欢迎提供下,咱们一起分析。
2024年03月24日
23 阅读
0 评论
0 点赞
2021-08-31
Kali安装配置过程中的一些nt操作和坑
Kali安装配置过程中的一些nt操作和坑安装过程中最后就选择安装的包,这个时候没有选择默认项自己选的。然后进去换源发现没有任何工具,我觉得kali的工具肯定是有源的。然后全网寻找发现了[em]apt install kali-linux-all[/em]但是当我输入的时候发现没有任何变化,这个时候我输入[hi]apt install kali-linux-[/hi]观察提示发现了[em]kali-linux-default[/em]输入无果又发现了[em]kali-linux-everything[/em]果断输入发现出现了kali的应用。没有驱动。WIFI在apt更新也是没有驱动,网上只有博通网卡的驱动。最后发现了英特尔官网有驱动。在官网驱动,寻找自己网卡的驱动包然后下载。 tar zxvf iwlwifi-9000-pu-b0-jf-b0-34.618819.0.tgz -C ./ #提取到当前目录 sudo cp iwlwifi-9000-pu-b0-jf-b0-34.618819.0/* /lib/firmware/ #复制到指定目录 sudo update-grub #更新grub完成所有的Win和Linux双系统的时间错乱问题那么为什么双系统切换之后系统的时间会错乱呢? 先了解以下UTC以及GMT。 格林尼治标准时间(GMT,旧译“格林威治平均时间”或“格林威治标准时间”)是指位于伦敦郊区的皇家格林尼治天文台的标准时间,因为本初子午线被定义在通过那里的经线。 协调世界时(UTC) 英文:Coordinated Universal Time ,别称:世界统一时间,世界标准时间国际协调时间, 协调世界时,又称世界统一时间,世界标准时间,国际协调时间,简称UTC。 GMT(Greenwish Mean Time 格林威治平时),这是UTC的民间名称。GMT=UTC。 因为两个系统计算时间的方式是不一样的,Windows直接使用系统硬件的时间作为本地时间,即操作系统中显示的时间是使用的BIOS中的时间。 而Linux/Unix/Mac则是把硬件时间(BIOS中的时间)当作UTC,其操作系统中显示的时间是对硬件时间计算后得到的,比如说北京时间是GMT+8,则系统中显示时间是硬件时间+8。而Windows显示的是硬件时间,所以两个时间会发生错乱。解决办法: Win10 新建一个文本文档,例如在桌面上,然后将一下内容粘贴到新建的文本文档文件中,之后保存并重命名为*.bat,双击运行一次即可。@echo off color 0a Reg add HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v RealTimeIsUniversal /t REG_DWORD /d 1 echo. Linuxtimedatectl set-local-rtc 1 --adjust-system-clock安装deepin-wine,安装QQ的时候报错无法定位软件包:libappindicator3-1_libappindicator3-1软件包安装失败这个时候直接定位安装是错误的,如果直接安装这个包也是存在依赖问题整改时候需要安装两个包libindicator3-7和libappindicator3-1直接[em]dpkg -i 包名[/em]进行安装安装完com.qq.im.deepin后发现无法输入密码和账号。这个时候检测输入法是不是启用的非官方输入法,这个时候手动切换成官方的默认英文输入法就可以。安装NVIDIA显卡驱动,目前我发现无法使用nvidia-prime进行独显和核显的切换,安装完成后只能使用独显.。(目前网上所有的办法这个问题都是没有解决的,在看官方文档看看能不能解决这个问题)sudo apt install -y nvidia-driver nvidia-cuda-toolkit
2021年08月31日
10 阅读
2 评论
0 点赞
2021-08-21
多个域名指向同一个IP访问文件造成的跨域问题
IPv6域名去访问IPv4域名底下的js文件报错贴一个报错代码Access to XMLHttpRequest at 'http://wlsp.icu:81/usr/plugins/Pio/models/pio/model.moc' from origin 'http://bt.wlsp.icu' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. l2d.js:1 GET http://wlsp.icu:81/usr/plugins/Pio/models/pio/model.moc net::ERR_FAILED解决问题分析是由于浏览器发现请求不同域名拒绝服务造成的需要构造请求头来证明资源可以使用(服务器为nginx)server { listen 8999; listen 80; listen [::]:80; listen 9999; listen [::]:9999; listen [::]:8999; server_name 192.168.0.109 wlsp.icu bt.wlsp.icu; index index.php index.html index.htm default.php default.htm default.html; root /www/wwwroot/typecho; # 在nginx服务器中添加下列代码 add_header Access-Control-Allow-Origin *; # 允许访问的域名 add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS'; # 应该是允许访问的方法, add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';} # 解释 Access-Control-Allow-Origin 服务器默认是不被允许跨域的。给Nginx服务器配置`Access-Control-Allow-Origin *`后,表示服务器可以接受所有的请求源(Origin),即接受所有跨域的请求。 Access-Control-Allow-Headers 是为了防止出现以下错误: Request header field Content-Type is not allowed by Access-Control-Allow-Headers in preflight response. 这个错误表示当前请求Content-Type的值不被支持。其实是我们发起了"application/json"的类型请求导致的。这里涉及到一个概念:预检请求(preflight request),请看下面"预检请求"的介绍。 Access-Control-Allow-Methods 是为了防止出现以下错误: Content-Type is not allowed by Access-Control-Allow-Headers in preflight response. 给OPTIONS 添加 204的返回,是为了处理在发送POST请求时Nginx依然拒绝访问的错误 发送"预检请求"时,需要用到方法 OPTIONS ,所以服务器需要允许该方法。贴一下大佬博客
2021年08月21日
7 阅读
2 评论
0 点赞
2021-08-20
给一个师哥搞文件发现的编码问题
图片图片以二进制流的形式为xff\xd8\xff\xe0\x00\x10JFIF\x00\x01\x01\x01\x00\x01\x00\x01\x00\x00\xff\xdb\x00C\x00\x06但使用burpsuit直接输出的时候却是乱码格式,然后使用python来输出的时候也为乱码格式(其实为UTF-8),也就是传输的时候为UTF-8的格式传输的。这个时候查看字符串的格式为 "str"。这个时候使用字符串转字节流的方式进行输出,输出了和代码中相同的字符串。这说明以二进制读取图片的时候读取的流为字节流。但是转换的时候会有错误,只要使用下面的代码忽略错误就行burp0_data.decode('utf-8','ignore')贴一下代码import requests with open('image.png','rb')as f: img=f.read() burp0_url = "https://" burp0_cookies = burp0_headers = burp0_data = b'------WebKitFormBoundaryT4EDabPQX1udNKUR\r\nContent-Disposition: form-data; name=\"qh_img\"; filename=\"777.jpg\"\r\nContent-Type: image/jpeg\r\n\r\n'+img+b'\r\n------WebKitFormBoundaryT4EDabPQX1udNKUR--\r\n' print(burp0_data.decode('utf-8','ignore')) r=requests.post(burp0_url, headers=burp0_headers, cookies=burp0_cookies, data=burp0_data) print(r) print(r.text)
2021年08月20日
19 阅读
1 评论
0 点赞
2021-08-03
Burpsuit失效后重新安装出现的问题
论Burpsuit的出现的问题1.java格式[warning]使用jdk1.8版本[/warning]必须使用jdk8,这样会避免大大小小的问题2.汉化使用在jdk11以上,-Xbootclasspath/p is no longer a supported option出现这个问题。这是因为jdk升级问题导致某些包被替换。于是使用以下命令启用汉化(但是汉化不完全)java -Dfile.encoding=utf-8 -javaagent:BurpSuiteChs.jar -noverify -javaagent:BurploaderKeygen.jar -jar burpsuite_pro_v2021.7.jar最后贴一个巨佬的BP的安装办法
2021年08月03日
8 阅读
4 评论
0 点赞
1
2