背景

最近熬夜听了听IEEE S&P的会议,其中一篇关于用LLM(Large Language Model)做bug修复的比较有意思,记录一下。

大语言模型(LLM)相信大家都不陌生了,最近非常火的chatGPT就是LLM的代表,这玩意儿号称什么都能干,在各大商用LLM的发布会上,demo都少不了写代码等专业性比较强的活,今天要介绍的这篇发表在S&P 23上的文章《Examining Zero-Shot Vulnerability Repair with Large Language Models》做了这么一件事:之前的工作证明LLM可以很好的生成代码,那么修bug的能力怎么样呢?来评估一下

1234

(这个老哥语速巨快,勉强听得懂在讲啥)

image-20230601163045106

方法

image-20230601163257269

这篇文章的方法论也是相当简单,因为针对的是黑盒的LLM模型,好像也没有什么高深的技术去搞。

首先收集一批有bug的程序,然后根据经验建立一个prompt模板池(prompt就是和LLM交互用的,我们的提问就是prompt),输入黑盒的LLM模型中得到修改后的程序,并经过测试验证该程序的bug是否被修复。

作者的贡献点主要在于多个黑盒LLM的measurement,除了一些商用模型,作者自己还搭了一个本地模型gpt2-csrc

image-20230601165202679

这里介绍一个比较有趣的(和其他AI模型做measurement不一样的)点。

LLM比较有特色的是,存在token的限制,token在英语里指一个短语。也就是说向LLM提问的输入size是存在限制的。这样的限制对于几十行几百行的程序也许没什么影响,但是对于几千行的bug程序就有问题了——输不进去。作者的处理方式是部分输入输出修复

1234

部分输入:作者只选取开头的#define以及有bug的函数作为输入,删除其他的程序代码,如果size还是超标,那就从上到下一行一行删代码,直到size合格为止

输出修复:部分输入的后果就是:LLM给出的修复程序也是不全的,作者的应对方法是进行代码匹配,一旦匹配到30个字母一样就说明匹配到了相同代码段,将修复程序插入到原程序相应位置即可。如果没有就依次减少匹配字母阈值,如果少于5个字母匹配到,就直接将修复程序插入到bug程序出Bug的位置

Take Away

最近LLM火爆潮流带来的结果是,arxiv上的LLM相关文章激增。但是搜了一下四大上的相关文章目前只有两篇,一篇是发表在USENIX 21 上的关于偷训练数据的《Extracting Training Data from Large Language Models》,第二篇就是本文了。综合来看目前对LLM的安全性研究还不是很深入,方法也比较naive(其实主要原因是LLM这玩意是黑盒的,就像USENIX 22 那篇研究Github copilot安全性的文章,没什么创新,但是热点摆在那,黑盒的也只能硬测,我也想不到有啥好办法,希望未来能看到大佬们出一些exciting的方法),在可以预见的未来,相关的安全性研究文章数量会有很大提升。

背景

Monkey测试是Google开发的、安卓系统自带的自动化测试工具。正如其名,monkey工具会像猴子一样对手机屏幕“乱点一通”,随机触发点击、滑动、组件启动等事件。Monkey本来是用作应用压力测试的,但是近年来(也不是近年了,一直都是),几乎所有的动态恶意软件检测相关的论文用的自动化测试工具都是monkey(包括我正在做的,嘿嘿)。所以觉得有必要总结一下如何高效利用Monkey测试。

Monkey Test命令

monkey的命令很简单,就是

adb shell monkey + 一些参数

我上网扒拉了一下相关的参数表,如下:

img

比较有趣的是monkey通过–throttle指定测试频率(ms为单位),也可以指定随机事件数,并通过这俩参数控制整个Monkey测试的总时间(两个参数乘一下就行了),并没有直接的时间限制参数。而发送事件类型里的trackball在手机行业基本没人用了,所以这个事件类型在测试里也很少被用到,其他参数按需设置即可。

测试高效化

monkey测试仅仅是这些简单的命令吗?当然不是。通过adb monkey我们可以让手机生成随机触发事件了,但是,总有一些意外触发的事件会影响monkey测试的效率。比如某一次motion操作可能会下拉状态栏,那么接下来的所有touch操作都会按到状态栏上,好点的结果是无事发生,浪费一点时间,而比较糟糕的情况下,monkey会错误的关闭状态栏里的wifi、流量等必要设置,造成整个自动化测试的结果误差较大。这种意外事件首先影响测试效率,其次,无论测试者是在做压力测试还是动态恶意软件检测,都会影响其测试精确度。

接下来总结一些测试过程中遇到的、使得Monkey测试高效化的trick:

禁用输入键盘

输入键盘是影响Monkey测试效率的一点,一旦打开键盘,monkey的事件触发全部点到按键上,时间就全部浪费了。虽然有些事件确实要输入一些内容才能触发,但是考虑一般情况,还是禁用键盘为好。指令为:

adb shell ime disable com.android.inputmethod.latin/.LatinIME

状态栏+导航栏隐藏

除了键盘,双栏——状态栏+导航栏也是

一般来说可以通过adb命令

adb shell settings put global policy_control immersive.full=*

来隐藏导航栏+状态栏,但是后来发现 monkey test中的 –pct-motion(滑动操作)会重新唤起双栏,所以这个方法不太可行。后来转念一想,我直接让屏幕显示区域里没有双栏的位置不就行了吗?于是考虑以下命令:

adb shell wm overscan //设置显示区域大小,坐标值为左、上、右、下

当参数设置为 0,-210,0,-210 时可以永久隐藏双栏,0,0,0,0恢复,也就是说隐藏adb命令为:

adb shell wm overscan 0,-210,0,-210

经测试此方法有效

自动授权

这个是比较重要的一环,因为安卓手机是经典的基于权限的系统,所以在大规模自动化测试时,每新安装一个app,刚打开时必定会弹权限请求窗口,如果不自动授权的话,会浪费很多时间。在pixel 3xl上我一共碰到过两种权限检查情况,第一种是最常见的:

0515 1

第二种是要full control的(比较危险,但是自动化测试要的就是危险哈哈)

0515 3

那么怎么自动授权呢,一个很直观的方法是获取到“CONTINUE”和”ALLOW“按钮的位置,然后使用adb模拟点击该位置坐标即可。那么为了获取按钮坐标,可以dump出当前页面的Xml,然后从Xml中识别对应元素坐标。

以”ALLOW“为例,使用命令

adb shell "uiautomator dump && cat /sdcard/window_dump.xml"

将当前ui dump到window_dump.xml并读取,然后找到ALLOW按钮相关信息

image-20230517143559295

node里几个关键信息是text、resource-id(凭借这两个信息即可确定是allow的node),然后bounds变量给出了ALLOW按钮的左上和右下坐标信息。模拟按键只需要按这两个坐标的均值即可,比如对于这里的[93,2075],[1347,2271],中值坐标为[720,2173],输入命令

adb shell input tap 720,2173

即可顺利触发ALLOW按钮

版本警告

压力测试可能不需要,但是动态恶意软件检测可能需要测试年份比较老的app,这些app的版本很旧,在比较新的安卓版本下可能会有如下警告信息:

0515 2

这里的话和上面的自动授权一样,读取XML并模拟点击一次即可。

参考

Monkey 命令基本参数详解 - 知乎 (zhihu.com)

介绍总结一下最近读的一篇论文《AIFORE: Smart Fuzzing Based on Automatic Input Format Reverse Engineering》,这是一篇发表在USENIX 23上的有关fuzzing的论文,它主要是在自动化输入格式推断(也就是标题所说的逆向工程)上做出了贡献。

背景

对于模糊测试(Fuzzing)来说,输入是十分重要的,高质量的输入能够使Fuzzer迅速扩大程序覆盖率并且快速发现程序bug。而目前致力于生成高质量输入格式的解决方案试图回答三个核心问题:

  1. 不同输入字段的边界在哪里 (input field boundary recognition)
  2. 如何推测某个字段属于哪种类型 (input field type identification)
  3. 如何利用输入格式的知识来指导fuzzing (utilization of input format)

然而,到目前为止,现有的解决方案都没能完整的解决这三个核心问题,或者说,各有各的局限性

本文方法

核心insight

由于输入字段是由基础块(Basic Blocks)解释的,所以输入的结构和语义信息可以从这些基础块得到,因此我们可以通过分析基础块来推断输入,然后利用推断结果进行智能模糊测试。

个人理解:其实这里就算是作者的核心贡献点之一,作者认为,之前的工作无论是从更粗粒度的function-level对输入字段解释,还是从instruction-level进行解释,粒度都是不合适的,basic block-level才是刚刚好。不过比较遗憾的是我在实验中只找到和instruction-level对比的实验,没有看到function-level的。

具体方法

image-20230512141330111

首先,针对核心问题1,AIFORE利用动态污点分析来了解哪些输入字节被每个BB处理。鉴于污点分析的结果,我们通过最小集群算法识别不可分割的字段来分割字段边界。

作者在这里提出了输入字段和基础块(BB)之间的关系:

​ 1. 在大多数情况下,不可分割字段中的字节在同一个基础块中一起解析

​ 2. 相对的,一个 基础块可能会处理多个输入字段并在运行时执行多次

其次,针对核心问题2AIFORE建立了一个深度学习模型来理解BBs,即预测它们处理的输入字段的类型。具体来说作者使用卷积神经网络(CNN),使用010 editor提供的ground truth数据作为训练集训练CNN,将BB和输入字段的类型联系起来。

这里就有一个有意思的问题:既然010 editor提供的是 ground truth,那作者还用CNN干啥?听这篇文章的审稿博士说,当时作者就被challenge了这个问题,于是在camera ready的这个版本,作者给出了如下解释:

  1. 010 editor并不总是对的,我们的ground truth也是通过人工处理来的,包括:删除冗余、移除未被目标程序解析的字段记录、手动检查记录以更正模糊语义类型的字段
  2. CNN本身也有优点,它在许多分类任务和二进制分析任务中被证明是有效的,也可以自然地过滤掉背景信息并有效地捕获有价值的特征。 在这篇文章中,背景信息是可以由多种类型的字段激活的常见指令。

最后,针对核心问题3,作者设计了一种基于模糊化过程中动态提取的格式的新型功率调度算法,以提高模糊化效率,具体来说,作者提出了一个利用格式知识的两步策略,即识别新的变体和优先考虑不经常测试的格式首先,挑选那些代码覆盖率明显不同的测试案例,重新分析它们的输入格式,因为它们很可能有不同的格式。其次,优先考虑那些在模糊处理过程中不经常测试的格式的种子,并增加其变异能力。

一些有趣的问题

  1. 在种子选取策略(power scheduling)上,作者更青睐于哪些种子?

    ● 作者选择具有明显不一样的代码覆盖率的种子并且重新分析它们的输入格式

    ● 作者优先考虑格式测试频率较低的种子

  2. 为什么选择语义类型而不是程序变量类型作为输入的推断格式?

    ● 语义类型提供更细粒度的信息,虽然语义类型的识别更具有挑战性,但是更有利于fuzz

  3. 作者种子变异策略是:一旦一个有价值的种子出现,模糊器就开始根据这个种子的格式进行变异,那么如果两个 “有价值 “的种子出现得很近,那么前一个种子就会被突变得不充分,这个问题如何解决?

    ● 作者设计了一个功率重新分配机制,当fuzzer卡住时,之前变异次数较少的格式会得到更多的能量,并且跳过具有完全变异的格式变量的种子

Take away

刚开始读的时候觉得这篇文章挺好,没啥问题,很正统的Fuzzing文章。但是后来又细看了一遍,还是有不少问题的。

  1. 作者本身的理论,作者认为在大多数情况下,不可分割字段中的字节在同一个基础块中一起解析,这也是他这篇文章的基石。BB-level的分析就是从这儿来的,然而我们可以看到,motivation example里作者自己就给出了反例:

image-20230512144550929

21行的magic number字段被分成了四个BB处理。作者给出的解释是,这样的例子非常少,且这并不影响fuzzig的效率,因为模糊测试是为了测试执行程序而不是提取准确与规范相比的字段边界。(原文)

我认为这就有点扯了,首先例子非常少是可以理解的,那么作者既然同时收集了010 editor的大量数据做训练集,为何不顺手做一下measurement证明一下确实是非常少呢,这白说的说服力有点低。而后面那个理由,我觉得就有点牵强了。。

  1. 深度学习的加入。深度学习模型CNN给核心问题2的解决带来了巨大便利,从实验结果我们也可以看到,CNN的效果是十分好的。但仔细一想,作者似乎并没有证明引入CNN的必要性,也就是说,其他工具是不是达不到这样的效果?AI领域的文章好像都是效果好就行了不必细究,但安全领域的文章还是多少得证明一下自己方法的必要性的吧

仅代表个人的一些浅见。

背景

最近曝光率超高的Large Language Model (LLM)——chatGPT在许多NLP任务中取得惊人的成绩,与人的互动中表现出的各方面的知识量更是让人叹为观止,比如医疗报告、代码生成等,也得到了安全界的广泛关注。

从安全角度出发,我们更关心LLM们会不会产生正确但是有漏洞的结果。比如它的代码生成能力就受到了质疑,前几天在arxiv上的的《How Secure is Code Generated by ChatGPT?》就chatGPT生成安全代码的能力展开研究

文章介绍

文章本身比较简单,因为ChatGPT本身不开源,整个工作流程那是相当的简单。。如下图:

image-20230427153553595

我们只能从prompt下手,那么问题就集中在:

  1. 如何选择合适的代码片段让chatGPT去生成新的
  2. 如何评估生成结果是否有漏洞

对于问题1,作者手工构建了21个不同编程语言的程序,并说这些程序会触发不同的Bug,本来感觉这里的描述太过人工化了,但看到后面发现这21个程序其实对应21个CWE(common weakness enumeration),那就还好

image-20230427154026895

作者的prompt是这么提的:

  1. 模仿新手程序员,要求chatGPT生成代码
  2. 针对出现的bug问chatgpt为什么会出现这样的行为
  3. 直接询问该生成代码是否安全

最终作者发现,有相当多的CWE情景下的代码会在chatgpt生成的情况下存在漏洞,而就安全性提问方面,chatgpt的表现也让人不是很满意,有些存在问题的代码,除非你明确提问这份代码可能存在特定类型的漏洞(例如存在反序列化漏洞 deserialization DoS and deserialization attack),ChatGPT才会“正确”回答(这里的回答正确也许也是刚好答案撞上了问题?)

对比

之前读过一篇关于copilot(github发布的代码辅助生成工具,基于gpt3开发的)生成代码安全性的文章,《Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions》,那篇文章在copilot出来后不久就发了,很幸运的蹭上热点发在USENIX 22上,实际上思路和这篇文章差不多,都是在几十个CWE情境下进行代码生成与评估。当然,那篇文章好在:

  1. 系统化了CWE情境(来自 MITRE 的“前 25 名”常见弱点枚举 (CWE) 列表)
  2. 半自动化的漏洞发现工具(CodeQL 或者人工check)
  3. 最终评估了1600+个程序

这篇文章从细节上还是差了些。

思考

这是一篇超前的文章

研究AI生成代码安全性的文章已经到两位数的规模了,因为之前一直在关注,所以chatgpt出来后就知道,一定会有《How Secure is Code Generated by ChatGPT?》的文章出现。然而我的困惑是,copilot这样的“专业”模型安全性可以用CWE这样的情景来描述,而chatGPT这种致力于“聊天”的工具,真的适合用代码安全性审查么?毕竟它本身的代码生成能力都有待考量。

如果看过OpenAI自己挂在arxiv上的《Training language models to follow instructions with human feedback》就会知道,他们在fine-tune的时候更多考虑的是模型的输出是否符合人类预言标准,并没有专门在代码上做考虑(也许私下做了没放出来?也有可能)

image-20230427160950220

而在我自己使用chatGPT过程中也发现,在生成代码的时候某些代码就是错的,跑都跑不起来,更不用说是否有漏洞了。但是又听说GPT-4的代码生成能力有了长足的进步(chatGPT是所谓的“gpt 3.5”),所以感觉可以考虑用GPT-4的API做一遍这篇文章的工作。

参考

[1] Khoury R, Avila A R, Brunelle J, et al. How Secure is Code Generated by ChatGPT?[J]. arXiv preprint arXiv:2304.09655, 2023.

[2] Pearce H, Ahmad B, Tan B, et al. Asleep at the keyboard? assessing the security of github copilot’s code contributions[C]//2022 IEEE Symposium on Security and Privacy (SP). IEEE, 2022: 754-768.

[3] Ouyang L, Wu J, Jiang X, et al. Training language models to follow instructions with human feedback[J]. Advances in Neural Information Processing Systems, 2022, 35: 27730-27744.

介绍

反病毒引擎通常是指厂商提供的、能够快速判断一个APK是否恶意的模型。为了轻量化,这些模型通常通过静态分析、签名匹配、规则匹配等开销相对较小的方法对一个APK进行解析判断。而它们依赖的签名与规则往往来源于专家知识,给出的判定结果就形成了所谓的”恶意家族“与”恶意行为倾向“。(毕竟一个恶意家族叫什么名字,就是这些专家根据特征定义的)

使用——恶意软件判断

反病毒引擎是个好东西,安卓恶意软件检测领域的很多文章都用它们来做恶意软件benchmark,然而直接用这些引擎给出的结果会有两个问题:

正常/恶意不一致

首先,不同厂商提供的反病毒引擎提供的结果可能是南辕北辙的,这是因为一些引擎可能没有在名单上加入某恶意家族的特征,导致识别失败。这就造成一个恶意应用可能被大部分引擎报毒而少部分引擎认为其正常。

学术界针对该问题的解决方法是:提供一个阈值(threshold)。比如某个工作一共采用了50个反病毒引擎,那么可以设定一个应用如果被15个以上引擎报毒,其就是恶意应用。根据这个阈值,目前有很多论文筛选提供了自己的恶意Benchmark。

现在学术界比较常用的工具是VirusTotal (VT)[3],给一个hash,它可以反馈63个反病毒引擎的报毒情况,下图是一个正常应用的报毒反馈。

image-20230419193753088

有意思的是,虽然大家都在用VT,但这个阈值究竟多少比较合理是很有争议的,big four与一些A类期刊的文章都有自己的阈值(也没给出解释,就是凭感觉选的),比如Drebin[6](很多安卓恶意软件检测文章里用作benchmark,引用数都2000+了)设置2个以上引擎报毒为恶意软件,AndroCT[5]设置10个级以上的引擎报毒就是恶意软件,APIGraph[7]设置15个为阈值。甚至有专门的工作做过相关研究[4]。

具体行为不一致

其次,即使不同的反病毒引擎提供了相同的报毒结果(善恶意判断),它们给出的报毒格式也是千奇百怪,比如下面选的一个来自Koodous的恶意软件

image-20230419200228650

可以看到有10个引擎报毒,但是有的引擎告诉我它是一个Trojan(Cyren、Yandex),有的引擎告诉我它是一个PUA(Ikarus),还有的告诉我它是Adware(K7GW),并且都各自带有奇奇怪怪的token(比如Adware ( 005321b21 ),这后面的是个啥?)

针对这个问题有两个解决方法,一个是VT自己提供的Popular threat label(如果用VT的API的话,在response的suggested_threat_label里),VT会直接推荐一个比较好的label;另一个是学术界给出的AV精炼(AVClass[1]),它的工作流程如下:

image-20230419201325950

可以将不同AV引擎的报毒结果精炼为比较合理的label。

进阶使用

一些工作关注到AV提供了丰富的报毒信息,并试图用其提供多标签,这里罗列两个[1] [2],它们就是通过前面提到的AV报毒结果精炼,然后再人工归纳总结出一些类别。第一篇是直接对给出的token进行归类

image-20230419202346152

第二篇认为之前工作的类别太杂了,于是只取里面的behavior-related和operation-related(但其实还是很杂)

image-20230419202301021

限制

好了,介绍完AV引擎的应用,接下来讲讲我认为目前还有其他什么问题。

目前的局限性聚焦于给恶意软件提供multi-label,像我之前一篇博客提到的,AV引擎给的信息太杂,并不适合作为多分类标签。我认为AV标签给出的信息和恶意家族是一个级别的,而且在一些情况下,AV给出的标签其实就是恶意家族标签,这是比多分类要细粒度的标签。这里举一个多分类的分类标准例子

image-20230419203237571

可以看到,这个六分类的标准是比较统一的,而且相互之间的重叠度不高,而AV给出的结果涵盖从下载方式、应用内容、攻击方式,相互之间的重叠度很高,我很疑惑如何只将一个恶意应用分类到这四十多个label中的一个。而反过来说,如果自己去定义multi-label标准的话,又很难做到覆盖度很高的同时重叠度又很低。如何给出一个大家公认合理的多分类标准,是值得思考的问题。

参考

[1] Sebastián M, Rivera R, Kotzias P, et al. Avclass: A tool for massive malware labeling[C]//Research in Attacks, Intrusions, and Defenses: 19th International Symposium, RAID 2016, Paris, France, September 19-21, 2016, Proceedings 19. Springer International Publishing, 2016: 230-253.

[2] García-Teodoro P, Gómez-Hernández J A, Abellán-Galera A. Multi-labeling of complex, multi-behavioral malware samples[J]. Computers & Security, 2022, 121: 102845.

[3] https://www.virustotal.com/

[4] Mohaisen A, Alrawi O. Av-meter: An evaluation of antivirus scans and labels[C]//Detection of Intrusions and Malware, and Vulnerability Assessment: 11th International Conference, DIMVA 2014, Egham, UK, July 10-11, 2014. Proceedings 11. Springer International Publishing, 2014: 112-131.

[5] Li W, Fu X, Cai H. Androct: ten years of app call traces in android[C]//2021 IEEE/ACM 18th International Conference on Mining Software Repositories (MSR). IEEE, 2021: 570-574.

[6] Arp D, Spreitzenbarth M, Hubner M, et al. Drebin: Effective and explainable detection of android malware in your pocket[C]//Ndss. 2014, 14: 23-26.

[7] Zhang X, Zhang Y, Zhong M, et al. Enhancing state-of-the-art classifiers with api semantics to detect evolved android malware[C]//Proceedings of the 2020 ACM SIGSAC conference on computer and communications security. 2020: 757-770.

背景

最近chatgpt爆火,它的对话反馈能力不仅在一般的对话场景下强于它的前辈们,在一些专业领域(比如计算机),更是让业内人士都叹为观止。我身边已经有不少人用chatgpt去做代码漏洞审查,代码补全等(和copilot类似了)。在我看来,一些专业知识要求较高的问题chatgpt都能回答的比较完美,在某种程度下,它比百度google更好用。

介绍

chatgpt_academic是github上一个开源项目,主要是基于openai提供的chatgpt api实现论文的一键润色、一键翻译等,还支持论文阅读一键总结,可以说是十分方便。体验下来,chatgpt的翻译水平比google免费翻译强,润色水平也比之前常用的deepl免费版要好,可以说是我们这些英语不好的人写英文论文的一大利器。

image-20230405152418056

部署

chatgpt_academic是用 gr 模块创建的一个基于浏览器的GUI界面,所以我考虑部署到服务器上,并做部署记录。

项目下载

直接

1
2
git clone https://github.com/binary-husky/chatgpt_academic.git
cd chatgpt_academic

API_KEY配置与代理设置

api_key需要从openai官网获取,在https://platform.openai.com/account/api-keys生成自己的私人密钥并复制到config.py即可。

代理我用的是clash,默认协议为http,需要注意的是

 1. 要开启允许局域网连接,否则服务器连不上
 2. 要关闭防火墙的网络defense,否则其他主机连不上

image-20230405155839566

如上图,我们需要设置的proxy如下

proxies = {

​ # [协议]:// [地址] :[端口]

​ “http”: “http://ip:7890“,

​ “https”: “http://ip:7890“,

}

安装依赖

瞄了一眼requirements.txt,包不多,所以我本来想直接在主环境安装依赖的,结果发现gradio>=3.23需要python3.7之后,而我的python3.6没这个版本,只好用conda去配一个新虚拟环境

1
2
3
conda create -n gptac_venv python=3.11
conda activate gptac_venv
python -m pip install -r requirements.txt

运行

服务器一般是不对外开放web端口的,所以我们需要指定端口并提前设置好开放,比如端口49499

先在config.py里修改端口(否则是随机端口)

image-20230405160810001

然后防火墙开放该端口

sudo iptables -A INPUT -p tcp --dport 49499 -j ACCEPT

sudo service iptables save

接下来就可以用http://服务器ip:49499 愉快使用学术chatgpt了

PS

首先是一个注意点,chatgpt账户的api是有免费额度的,之前是18美元后来是5美元,大概够反馈100万个token的,后续gpt3.5收费是0.002刀/1k token,所以要节省使用

然后是一个有意思的地方。如果用vscode的terminal而不是正常shell运行上述代码,Web服务会直接在本机开启而不是服务器,换句话说,你执行了服务器的代码,但指定的server是本机。这就有点疑惑了,按理来说在vscode的terminal上执行远程服务器代码,走的一样的ssh,虽然lauch的是0.0.0.0,但应该和xshell这些没啥区别啊,疑惑.jpg

参考

[1] binary-husky/chatgpt_academic: 科研工作专用ChatGPT拓展,特别优化学术Paper润色体验,支持自定义快捷按钮,支持自定义函数插件,支持markdown表格显示,Tex公式双显示,代码显示功能完善,新增本地Python/C++/Go项目树剖析功能/项目源代码自译解能力,新增PDF和Word文献批量总结功能 (github.com)

[2] https://chatgpt.cn.obiscr.com/blog/posts/2023/How-to-get-api-key/

简介

adb是安卓开发者常用的调试手段,通常来说开发者通过usb数据线连接PC和设备,然后开启开发者模式就可以打开shell开始调试了,但是总有一些情况需要远程调试(比如疫情被困在家)。这里介绍两种远程adb的方法。

方法一:adb connect

adb自己提供一种远程连接的方法,那就是adb connect。开发者可以使用adb connect ip:port的方式连接到一个远程安卓设备上,具体使用方法如下:

adb shell

su

mount -o rw,remount /system/挂载系统分区

echo "service.adb.tcp.port=5555" >> /system/build.prop //设置5555端口为adb端口

adb reboot //重启

然后远端就PC就可以通过IP:port连接到该手机,具体指令为:

adb connect IP:port

一次实际操作如下图所示,手机端:

image-20230323192156121

远端PC:

image-20230323192454811

我们可以看到,这种方式有两点要求:

1.手机root以添加永久的adb无线调试端口,(否则会报错,因为 /system/build.prop是个只读文件)

2.手机和远端PC处在同一个子网下,换句话说,二者要ping的通,否则connect根本找不到对应ip

方法二 端口转发

第二种方法是端口转发,成功后可以直接像在本地PC一样操作adb。这种方法需要先了解一下adb的原理。

adb原理.drawio

如上图所示,adb调试由三部分组成,分别为安卓设备上的deamon、本地PC的client和server。其中server负责查询连接到本地的可调试设备有哪些,通常占用5037端口,client负责输入命令。而我们只需要将本地的5037端口转发到远端PC的5037端口去(红线部分),那么就可以在远端PC实现adb命令。

具体实践如下图,我使用tabby terminal可以一键端口转发

image-20230323195839010

需要注意的是,这里远端PC必须adb kill-server,因为要保证远端的5037端口不被占用。方法二相比于方法一的好处是,在多台安卓设备时可以很方便的adb devices检索识别,而方法一需要苦哈哈的一个个找ip进行connect。但这仍然需要远端PC和本地PC ping的通,如果不在一个子网的话,还是得通过代理等方式先解决这个问题。

参考文献

[1] (23条消息) ADB远程桌面连接本地手机_adb远程连接手机_welsonx的博客-CSDN博客

[2] (23条消息) adb 连接安卓手机远程调试_adb远程连接手机_某呆啊的博客-CSDN博客

简介

看了今年几篇CCF A类期刊的安卓恶意软件检测综述[^1] [^2] [^3],发现大家对按照粒度划分的恶意软件检测方法都不太感冒,尤其是恶意家族分类相关文章的介绍比较少,也没有讲恶意家族分类和恶意软件多分类的区别。本文尝试综合性的介绍当前安卓恶意家族分类的研究现状与待解决问题。

恶意软件检测一直都是信息安全领域的一个重点研究问题,而安卓作为使用最多,占比最大的移动设备系统,产生的安卓恶意应用数量也在逐年飙升。因此,安卓恶意软件检测(也可以叫安卓恶意应用检测)是恶意软件检测领域的重要组成部分。在我看来,安卓恶意软件检测按照粒度可以分为三个级别,(1)恶意/正常软件分类(二分类),(2)恶意软件多分类(多分类),(3)最后是本文将要详细介绍的恶意家族分类(多分类)。

恶意软件二分类

首先是恶意/正常软件分类,这个最好理解,通常研究者(或者开发者)通过基于签名的方法,或是通过训练一个AI模型,构建一个恶意软件分类器。当一个安卓应用被输入到这个分类器里,分类器会根据提取的特征进行判别,输出的结果是正常或者恶意(二分类)。下图是一个经典的基于动态分析的深度学习二分类器结构(DL-Droid)

image-20230309135104591

恶意软件多分类

其次是恶意软件多分类,相比于恶意/正常的软件分类,恶意软件分类会在判断出恶意软件的基础上,给恶意软件打上多标签,这种多标签代表着该恶意软件是什么类型的恶意软件。比如一个大量发送短信的安卓应用很可能是资费消耗类型的恶意软件,而大量调用安装相关API的安卓应用大概率是流氓安装类型的恶意软件。那么问题来了,安卓恶意软件到底应该分为哪几类呢?根据我看下来的文章,大家都有自己的标准,也各有各的道理。比如TDSC 22的一篇文章,它做了六分类,而我国工信部在19年的《关于开展APP侵害用户权益专项整治工作的通知》中提出的八分类。目前国际上没有什么统一的标准,而我觉得,如果要构建相应的标准,还是得用实验说话——收集一个大规模、时间跨度长的安卓恶意应用,如何分类能使它们分成相对泾渭分明的聚簇,这样的分类其实是比较好的分类标准。下图是一个恶意软件六分类的分类器结构(MLCDroid)

image-20230309141138015

恶意家族分类

最后是恶意家族分类。顾名思义,恶意家族分类就是对目前病毒引擎总结出的所谓“恶意家族”,利用机器学习的算法进行分类验证。本文通过三个RQ来对这个细粒度的研究领域做介绍:

RQ1. 恶意家族分类和恶意软件多分类有什么区别?

这个问题可以从两个方面回答,一方面,二者的适用范围不同,一个恶意软件一定会被恶意软件多分类识别,而它不一定属于某个恶意家族。换句话说,恶意软件多分类针对的是所有的恶意应用,而恶意家族分类针对的是恶意软件中的一部分——带有恶意家族标签的那些恶意软件。当然不可否认的是,恶意家族分类器也可能对全体恶意软件进行预测,从中选取出之前从未见过的恶意家族/对已有恶意家族查漏补缺。但这种全面性的预测因为同时需要AI方面的深厚功底以及针对恶意家族的大量专家经验(不管是新恶意家族还是查漏补缺,都需要人工检查,包括代码静态分析和动态分析),因此还没有人做过这方面的研究。

RQ2. 目前的恶意家族分类研究现状如何?

目前在学术界的研究前沿,采取静态/动态方法去做恶意家族分类的研究都有,我这里分别介绍几篇静态/动态方法做的恶意家族分类的论文。

静态分析

绝大部分静态分析技术使用的特征其实和安卓恶意检测非常类似(可以说是一样),都是API调用、权限、二进制文件中提取的一些metadata等。RevealDroid[^4] 提取静态特征(分类的API调用。基于反射的功能、二进制文件)进行恶意软件检测和家族识别,在实验评估部分使用包含 54,000 多个恶意和良性应用程序的大型数据集评估 RevealDroid 的准确性、效率和混淆弹性(抗混淆能力),在恶意软件检测上做到了98%准确率,恶意家族检测做到了95%准确率。另一篇工作大开脑洞[^5],他们通过读取dex可执行文件的二进制代码并储存为8-bit无符号整数来产出[0,255]的整数序列,这些序列是可以表示一幅灰度图的。换句话说,他们将一个安卓应用转换为一个image(不是镜像文件,而是真的图像),然后用cv领域的算法对这些图像进行分类处理。下图是一个恶意应用的灰度图和对应的热度图。

image-20230313220605331

然后这篇论文的分类效果居然还很好,做到了0.96-0.97的准确度。

动态分析

动态方法的文章就有点八仙过海,各显神通的意思了,有监控系统调用的,有监控API的,而监控API还会分成监控APP本身和监控系统,但据我观察这块的文章其实在监控点方面没有太大的创新,基本都是用现成的工具,比如sTrace,Droidfax等。这里只介绍一篇最有趣的,通过实时的资源消耗情况进行侧信道分类恶意家族的方法[^ 6] 。具体来说,它在模拟器上跑APP,间隔固定时间去提取/proc目录下的资源消耗情况(CPU,内存,网络使用等)作为特征,最后恶意家族分类指标0.82。

小结

总的来说,在恶意家族分类领域呈现动态方法效果不如静态方法的现象。我认为主要原因有两点:首先,目前所谓的恶意家族分类主要是由病毒引擎发现并命名,这些引擎通常使用静态方法,通过字符串匹配和签名匹配的方式进行传统识别(比如VirusTotal用到的那几十个引擎),所以反过来,静态的机器学习方法效果也会比较好,这是因为给定的验证集(来源于这些静态引擎)本身就很迎合静态方法。其次,目前的动态方法其实很难具备描述一个恶意应用全部语义的能力,这种限制又有几点原因:(1)大部分工作用模拟器运行安卓应用并进行动态分析,众所周知,安卓恶意应用可能具有反模拟器和反沙箱能力,所以模拟器很可能跑不出恶意应用的恶意行为; (2)即使使用真机跑应用,很多恶意家族的特性是非常相似的,可能只在关键字符串上有所不同,比如smspreg和smspay,都会大量调用sms相关API,很难在framework层做出区分。

RQ3. 目前恶意家族分类还有什么可做的?

其实通过上一个RQ我们就可以发现,目前动态方法做恶意家族分类的效果不是很好,0.8+是常态,而静态方法都快卷到0.99了。然而,随着技术的发展,在可预见的未来,恶意应用的加壳与混淆会越来越严重,对抗样本攻击也会越来越巧妙,传统的静态方法的效果会逐步下降[^7] ,因此动态方法还是大有可为的。而要用动态方法,首先避免不了的问题就是如何选取合适的特征,以收集到足够丰富的语义去区分各个恶意家族。

参考文献

[^1]: Liu K, Xu S, Xu G, et al. A review of android malware detection approaches based on machine learning[J]. IEEE Access, 2020, 8: 124579-124607.
[^2]:Liu Y, Tantithamthavorn C, Li L, et al. Deep learning for android malware defenses: a systematic literature review[J]. ACM Journal of the ACM (JACM), 2022.
[^3]: Razgallah A, Khoury R, Hallé S, et al. A survey of malware detection in Android apps: Recommendations and perspectives for future research[J]. Computer Science Review, 2021, 39: 100358.
[^4]: Garcia J, Hammad M, Malek S. Lightweight, obfuscation-resilient detection and family identification of android malware[J]. ACM Transactions on Software Engineering and Methodology (TOSEM), 2018, 26(3): 1-29.
[^5 ]:Iadarola G, Martinelli F, Mercaldo F, et al. Towards an interpretable deep learning model for mobile malware detection and family identification[J]. Computers & Security, 2021, 105: 102198.
[^ 6]: Massarelli L, Aniello L, Ciccotelli C, et al. Android malware family classification based on resource consumption over time[C]//2017 12th International Conference on Malicious and Unwanted Software (MALWARE). IEEE, 2017: 31-38.
[^ 7]: Aghakhani H, Gritti F, Mecca F, et al. When malware is packin’heat; limits of machine learning classifiers based on static analysis features[C]//Network and Distributed Systems Security (NDSS) Symposium 2020. 2020.

基本信息

论文标题:《Poirot: Probabilistically Recommending Protections for the Android Framework》

发表会议:CCS’ 22

简介

​ 安卓系统是一个经典的基于访问控制的系统,而对权限控制的不一致性问题一直都是安卓安全的一大痛点。这篇文章主要研究安卓Framework层不一致的安全策略,这种不一致可能允许恶意行为者不正确地访问敏感信息。

​ 然而,作者发现现有的方法受到高误报率的影响,因为它们完全依赖简单的收敛分析和基于可达性的关系来推理访问控制实施的有效性。

​ 作者观察到resource-to-access的控制关联其实在安卓环境中是高度不确定的,所以作者提出了一个利用概率推理的工具,用来给安卓framework层API提供保护建议,这种概率推理方法的优点是FP较低。

贡献

 1. 作者开发了Poirot,一种可以为Framework层资源提供概率保护建议的工具;Poirot融合了概率推理与静态程序分析,解决了静态访问控制推理的不确定性问题。
 2. 作者提出的方法通过丰富的语义、结构和数据流关系补充了传统的可达性分析,这些关系更好的展示了安卓框架层资源和所需保护之间的联系。
 3. Poirot在四个安卓镜像上表现很好,大大抑制了两个SOTA工具(Ace Droid和Kratos)的FP。

背景和motivation

背景

​ 作为位于安卓中间件的java库与系统服务的集合,安卓框架层为开发者提供公开的API,用来访问完整的安卓功能,比如相机、蓝牙等。

​ 每个安卓API通过访问一个或多个安卓资源来实现它的功能,这些资源可以分为三类:

1. 字段访问和更新
1. 内部方法调用(比如native层的方法,文件访问方法,非公开服务方法)
1. API调用(一个API可能会调用另一个API,这时另一个API也算是资源)

​ 框架层的开发人员负责实现基于资源类别、敏感性的访问控制,比如LocationManagerService 中的 API requestLocationUp dates() 应该需要位置访问权限,访问控制检查确定两点:

 1. 调用应用程序拥有特定权限或满足特定条件(例如,分配了一个特定的 UID)
 2. 调用的用户是否有足够的权限访问资源。

​ 不幸的是,由于缺乏精确和完整的安全性规范,访问控制的实现往往是不协调和不一致的。 这促使了不一致检测解决方案。

motivation

目前大部分检测访问控制不一致性的工作其实都在用“提取和比较沿不同路径的访问控制到同一个资源“的方法

Kratos:给定一个安卓资源,使用路径不敏感分析来提取到该资源路径上的显式安全检查(比如权限检查或包名检查),然后进行收敛分析确定汇聚到同一资源的路径,并比较每一条路径提取的检查的集合以检测潜在不一致。

AceDroid:解决了特定的一个安卓访问控制的特性问题(即,安卓的访问控制实现往往是联合或者不联合的,并且可能在句法上不同但是语义等价),AceDroid能够通过进行路径敏感分析,对更广泛的安全检查进行建模并规范化不同的访问控制检查

ACMiner:前两者都是人工去定义表征安全检查的模式,ACMiner通过追溯抛出的安全异常来半自动的识别安全检查。

上述工作有两大缺点:

  1. 他们可能无法准确识别给定的访问控制检查,因此有大量FP
  2. 他们只检测显式的基于可达性的不一致性,因此可能会遗漏大量的隐式不一致

image-20230227201650941

上图中(A) PMS.flushPackageRestrictionsAsUser():刷新一个指定用户对磁盘的特定访问包限制

​ (B) PMS.installExistingPackageAsUser():为一个指定用户安装已有的包

不精确的访问控制检查目标识别

现有的工具认为收敛于相似操作的API是关联的,比如上图中同样调用mSettings.writePackageRestrictionsLPr()的两个API,被认为是关联的,然后A只需要进行user ownership/ privilege检查,而B还需要signature permission检查,所以现有工具认为存在不一致性,A需要的权限更少。但实际上,A和B是完全不一样的功能

这种FP出现的原因是简单的不一致性分析无法精确的查明要进行访问控制检查的目标

而实际上,作者认为应该这样识别:

  1. A中的user检查部分(绿色)可能和黄色部分的操作相关(因为他们的名字和参数值相关)
  2. B中的权限检查(红色)可能针对黄色区域的两个install方法(因为名字)
  3. B中的user检查(绿色)可能针对黄色部分和紫色部分(因为都用userid)

基于三步分析,作者推测writePackageRestrictionsLPr() 这个汇聚点(两个API同时调用的方法)其实和权限检查没啥关系,因此应该是个FP

隐式访问控制不一致

以前的工作基于可达性将目标资源和权限关联到一起,或者资源是否可以从受保护的 API 访问。比如A里调用的几个方法,因为都可以直接从这个API调用,因此应该至少需要A这个API的权限(绿色部分)

尽管这种显式的可达性分析可以进行资源保护的大致关联,作者观察到资源可能通过一些隐式关系(包括语义、数据流和结构)关联到相关的保护

image-20230227205529372

图中这个例子B中,一个第三方应用可以操纵mAdminMaps中的内容,而这个资源用来触发setRuntimePermissionGrantState() ,紧接着就可以触发底层的特权操作(黄色部分)

因此,作者认为需要对资源和资源之间的各种关系,并聚合相关的控制访问信息,这样才能处理隐式不一致。

而因为作者观察到的关系并不总意味着某种保护关联,因此这种因此不一致存在不确定性

而用作者的方法进行上图的不确定的方法如下:

  1. 对C的静态分析表明grantRuntimePermission()方法需要权限ADJUST_RUNTIME_PERMISSION
  2. 作者将这个信息传递到它的调用者A setRuntimePermissionGrantState() ,这表明A至少应该进行至少相当于ADJUST_RUNTIME_PERMISSION的权限检查
  3. 作者观察到,A并没有进行这样的权限检查,与此同时,A使用与字段读取相关的触发条件检查,也就是mAdminMaps 控制访问,作者认为这种字段相关的检查要纳入考虑,它可能和权限检查起相同作用
  4. 作者将3中得到的隐式访问控制信息传播到mAdminMaps的写入点,也就是B
  5. 作者在B中发现了这一不一致性(红色部分)

此外,图中其实还有一个辅助判别的信息,那就是A中6号紫色部分,这种相同判别条件的互斥操作大概率需要类似的访问控制,我们可以认为黄色的访问控制可以传播到6号紫色部分

作者的解决方案

围绕概率,根据安卓隐式关联给的提示(语义、数据流和结构)类型和数量,计算一个资源r关联到一个保护p的概率

方法

给定一个安卓ROM,Poirot预处理框架层和系统classes来识别系统服务和他们的API,它静态的分析API来识别可访问资源,并以路径敏感的方式进行访问控制检查。由于识别的资源数量会严重影响概率推理,所以工具会预处理清除掉不相关的代码块。

基础facts收集

Poirot首先收集一些基础信息,使用过程间路径敏感分析,该工具识别通向每个资源的可能路径,对于每一个路径,工具提取所有的访问控制检查并将它们的集合作为这个路径的代表,然后它生成一个随机变量,用来表示路径上的一个资源要求这个集合里所有访问控制检查的概率,如果这个资源被发现要其他的保护,那么给它加一个新变量

访问控制约束检测

对每个资源Poirot生成访问控制约束,其实就是通过分析访问控制属性将先验概率分配给之前的那些随机数,也就是之前收集的基础facts里的访问控制检查和每个资源之间的联系。作者把一对一的访问控制依赖(一个访问控制检查只关联一个资源)概率设为0.95,一对多的设为0.6

隐式约束检测

这种隐式约束(结构、语义、数据流关系)提供了一个资源链接到另一个资源的置信度。

作者一共建模了七种隐式约束,分别是:可达性、触发条件、互斥性、名称关联、Getter-to-Setter、数据流和参数流约束。

概率推理

收集到的概率约束会传给概率推理引擎,并给出最后的保护建议,开发者可以将每个建议与对应API的实现进行比较,以检测访问的不一致性

访问控制约束

在从 API 收集访问控制约束之前,作者首先使用程序分析来减少需要分析的资源,具体来说,清除了一些常用的API里的资源,这些API常用于资源检查、日志记录和metric收集。

一些定义

image-20230227221356990

基础访问控制facts

image-20230227221519955

首先,作者在ICFG上进行前向的控制流分析,并识别目标资源所控制依赖的条件分支。

然后,作者处理分支来推断访问控制模式并使用defuse链提取其他相关约束,如果多条约束在相同路径上被发现,使用and进行合并,如果相反,有多个ICFG路径到达一个目标资源,就用OR进行合并

对于每一个路径,Poirot引入一个新的随机变量来表示目标需要这个路径上的约束集合的概率

访问控制约束

其实就是之前讲的,一对一0.95,一对多0.6

隐式约束

image-20230227222851133

首先作者对隐式建模的结果如上图,然后进行每一种隐式约束的详细讨论,这里不展开

getter-to-setter里是将所有的get-set都联系起来,提到的FP是对一个共享Buffer可以append,但是不能读

需要注意的是它使用聚合算法,也就是说比如一条路径上资源r对保护p的概率是0.1,另一条路径上资源r对保护p的概率是0.9,那么最后聚合后的概率会比0.9大

实践

Poirot由两个组件构成,一个是静态分析组件(建立在WALA上,并依赖Akka Typed进行并行分析),另一个是概率分析组件,使用(ProbLog作为概率分析引擎)

image-20230227231038920

在一个AOSP API上表现很好

evaluation

RQ1 评估Poirot的保护建议机制

对于每个系统服务,作者收集10%API作为测试集,其他90%API作为基础facts的训练集,最后准确率还可以

RQ2 不同超参的实验

RQ3 先验概率值的影响

就是之前table1里预先设置好的概率的影响,该实验证明影响不大

RQ4 概率约束的影响

统计了每种约束类型的比例

image-20230227231823265

RQ5 overhead

看表现overhead可以接受

image-20230227231918457

RQ6&7 检测不一致性的能力

作者分析了来自 AOSP、亚马逊、小米和 LG 的四款 ROM,结果如下:

image-20230227232111320

总结

Poirot这篇文章抓住了安卓系统不一致性检测的一个痛点,那就是静态分析不可能完全准确的识别出资源和保护之间的联系,为此,它提出用资源-保护-概率替代原有的资源-保护关系。我认为这种想法非常好,概率是更精确的资源-保护的推荐描述,算是一个细粒度的体现。

但这篇文章的缺点也很明显,从先验概率的具体值到隐式约束的七种建模,作者使用了大量的启发式规则,这使得

  1. 实验结果的准确性受到先验概率值的影响(虽然作者的RQ 3证明先验概率的小范围波动不影响结果准确性,但仍然没有给出确定具体值的理由)
  2. 隐式约束的建模可能存在遗漏(比如作者提到第三方ROM里一些独特的权限检查方法),使得工具存在漏报

上周实践了nfs挂载,总的来说,nfs是基于文件级别的、依赖于IP进行访问控制的网络存储共享协议。

iSCSI

iSCSI(Internet Small Computer System Interface,发音为/ˈаɪskʌzi/),Internet小型计算机系统接口,又称为IP-SAN,是一种基于因特网SCSI-3协议下的存储技术,由IETF提出,并于2003年2月11日成为正式的标准。

作为光纤通道(FC)的一种IP替代方案,它和FC一样,都是将块级的SCSI命令进行封装发送。也就是说,和NFS相比,它是基于数据块的网络存储共享协议。

iscsi是基于TCP/IP和scsi协议的一项技术,任一主机通过iscsi target功能成为iscsi存储空间的共享者/服务端;同样的,任一主机通过iscsi initiator(初始化用户)功能可以成为iscsi存储空间的使用者/客户端;限制iscsi的相互之间的联系需要配置规则,在无规则情况下,双方是可以建立联系的
iSCSI共享存储流程

实践

用手里的kali虚拟机克隆一下,弄两台出来做实验

服务端:192.168.183.132

客户端:192.168.183.131

服务端

首先给服务端扩展一个用于共享的磁盘块,VMWARE的话直接设置里扩展一个SCSI磁盘就好了,比如下图的磁盘2

image-20230218161612768

之后用lsblk查看系统磁盘情况

image-20230218161936348

/dev/sda就是新扩展出来的磁盘,对其分区

image-20230218162616135

之后需要安装targetcli

yum直接yum install targetcli -y

作为经典的debian系linux,kali使用apt做包管理,需要sudo apt install targetcli-fb -y

如果提示找不到targetcli相关包,先apt update即可

接下来targetcli定义块设备与target

image-20230218164513373

创建客户端与服务端的识别名与卷

image-20230218165406285

这里也可以直接create,系统会自动给你分配识别名

客户端

客户端也需要先安装包

yum:yum install iscsi-initiator-utils

apt:apt install open-iscsi -y 没权限就加sudo,找不到包就apt update

之后 sudo vim /etc/iscsi/initiatorname.iscsi

image-20230218171756866

添加客户端识别名

修改完毕后,需要systemctl restart iscsid 重启该配置文件

之后通过两条命令发现并登录iscsi

sudo iscsiadm -m discovery -t sendtargets -p 192.168.183.132

sudo iscsiadm -m node -T iqn.2023-02.com.test:server -p 192.168.183.132:3260 -l

image-20230218171957290

image-20230218172057643

挂载成功,查看挂载前后的磁盘情况

挂载前:

image-20230218172157966

挂载后:

image-20230218172219079

这里需要注意的是,dev/sdb1已分配的磁盘也挂载过来了,意思是我们在服务端那边做的分配情况会同步过来;当然我们在服务端那边不分配,直接挂载过来,然后在客户端再进行分配也是可以的。

之后就是传统的Mount挂载了

先通过sudo mkfs.ext4 /dev/sdb1 格式化磁盘

然后sudo mount /dev/sdb1 /mnt/iscsi挂载到需要的文件夹

image-20230218172948313

总结

最近看了一些NFS与iscsi的相关资料,这两种协议目前说不上谁好谁坏,只能说各有特点。从文件系统的管理角度,NFS使用文件级别的共享,而iSCSI使用数据块,不关心文件系统到底存储了什么。这就导致了NFS系统对存储在其中的应用数据具有更高的可视性(比如我用过的黑群晖,感觉非常方便),不过听说最近在VMware的VAAI中实现的SCSI T10也为块存储增加了感知功能。从安全角度看,两者都支持IP安全限制,而iscsi还内置了对双向挑战握手认证协议的支持。此外,NFS v2完全基于UDP实现,不过v3之后也支持了TCP/IP协议。

这两周实践了两种网络存储共享协议,NFS和iSCSI,主要走了一遍部署和挂载的流程,其实他们俩实际上性能与特点的差别(尤其是实际部署后流量控制、网速差异)是没实验出来的,有待以后有条件了再做实验。

参考资料

[1] (23条消息) iscsi服务器搭建_bojiSAMA的博客-CSDN博客_iscsi存储服务器搭建

0%