### 接受指南 由于Metasploit框架拥有数以万计的依赖于日常，一致和无差错更新的用户，Metasploit核心开发人员为了考虑对新框架功能和新的Metasploit模块的请求，采用了相当高的标准。我们当然非常高兴接受来自社区的模块和改进，所以为了鼓励开放和透明的开发，本文档概述了开发者应遵守的一般准则。这样做最大限度地提高了将您的工作合并到官方Metasploit分发包中的机会。 #### 模块添加 Metasploit的大多数开源社区支持都是以Metasploit模块的形式出现的。应该考虑接受以下内容，但是请注意，这些指导原则通常被认为是“应该”而不是“必须”，因为总是存在例外情况 - 特别是在涉及新的攻击方法和新技术时。 模块应该通过[msftidy.rb](https://github.com/rapid7/metasploit-framework/blob/master/tools/msftidy.rb)并遵守[CONTRIBUTING.md](https://github.com/rapid7/metasploit-framework/blob/master/CONTRIBUTING.md)指南。两者都友Metasploit分发。有关如何解决空白问题的某些信息，请参考[“ 样式提示 ”](https://github.com/rapid7/metasploit-framework/wiki/Style-Tips)。 模块应该有一个明确且明显的目标：exploit模块应该得到一个shell。post模块应该导致特权升级或战利品。Auxiliary模块是一个“其他”类别，但应限于一些定义明确的任务 - 通常是收集信息以启用exploit或post模块。 考虑到设置多个有效载荷的复杂性，模块不应该启动其他模块。这些操作通常是外部UI的自动化任务。 拒绝服务模块应该是不对称的，至少有一些有趣的功能。如果它与synflood相媲美，则不应包括在内。如果可以和Baliwicked相媲美，那就应该包括在内。盘旋在线上的模块，比如slowloris，可能会因为一些理由包含在之中。 模块应该能够按照预期的最小配置运行。默认值应该是聪明的，通常情况下是正确的。所有内存地址（即JMP ESP或ROP小工具）都应该是“目标”下的元数据的一部分，并记录下来（它指向哪些指令以及什么DLL。如果攻击是针对特定硬件（即路由器，PLC等），或针对不是免费的软件（并且没有可用的试用版/演示版），请记住提交二进制数据包捕获(pcap格式)，演示模块利用实际工作。 请不要使用字母编码器来避免BadChar分析。将有效载荷中的EncoderType字段设置为避免进行真正的BadChar分析的模块将被拒绝。这些模块在现实世界中几乎总是不可靠的。 exploit rank定义可以在[exploit rank](https://github.com/rapid7/metasploit-framework/wiki/Exploit-Ranking)页面找到 如果这么做微不足道的话,exploit模块应该实现一个check方法。通过baners或网络协议暴露的版本,如果有可用的补丁更改此版本，那么check方法应该总是返回. 如果某个模块(auxiliary 或者post)从受害机器获得某种信息，则应使用以下一种（或多种）方法存储该数据： * `store_loot()`: 用于存储盗窃文件（包括文本和二进制文件）和例如`ps -ef` and `ifconfig`命令的"屏幕捕获"。文件本身不需要是 `forensic-level` 级别的完整性 - 它们可能被post模块解析为渗透测试者提取相关信息。 * `report_auth_info()`:用于存储可以被另一个模块立即重新使用的工作凭证。 例如，转储本地SMB散列的模块将使用这个，就像读取用户名的模块:特定主机和服务的密码组合一样。 具体来说，只是“可能是”的用户名和密码应该使用store_loot()来代替。 * `report_vuln()`:使用特定漏洞的Auxiliary 和 post模块应该在`repost_vuln`成功调用.请注意，exploit模块自动将report_vuln作为打开一个会话的一部分 不需要特殊调用 * `report_note()`:如果上面三种更合适,模块应该尽量避免`report_note`,但是可能前面三种不是合适的.`report_note`应该总是设置一个旧式风格的`:type`,例如`domain.hosts`所以其他模块可以更容易在数据库找到它们 模块应该利用正常的Metasploit API。例如，他们不应该尝试使用本地Ruby创建自己的TCP套接字或应用程序协议，而应该通过Rex和Rex::Proto方法调用套接字。这确保了与全套框架功能（如pivoting和 proxy chaining）的兼容性。 Web应用程序攻击通常是不喜欢的(SQL,XSS，CSRF)，除非模块可以可靠地导致getshell或执行某种有用的信息泄漏。即使在这种情况下，模块也应该如上所述“正常工作”。 Web应用程序攻击应该仅限于流行的,广泛部署的应用程序。例如，针对在CMS机器上产生shell的受欢迎的CMS的SQLi模块将是受欢迎的.而导致私人Facebook配置文件公开的模块不会(Facebook只有一个已部署的实例). Web应用程序攻击应该实现一个HttpFingerprint常量。 模块应该只是列出目标 你实际测试exploit中 如果从未在上面测试,尽量避免假设它可以工作在某一个特定系统. 目标条目上方的注释，指示有关给定目标(语言包，修补程序级别等)的附加信息,可以帮助其他开发人员创建更多目标并改进模块。 模块可以运行未经修补和未公开的漏洞。然而，Rapid7很乐意遵循Rapid7政策协助披露流程。此策略提供了从联系供应商到exploit被释放,一个固定的90天时间，Rapid7员工发现的所有漏洞均遵循此流程。无论披露的处理方式如何，提交者都将获得该漏洞的全部荣誉和最终的利用模块。 ### 框架增强 一般来说，Metasploit框架的新功能应该从插件开始。如果功能变得有用和流行，我们可以更密切地整合它，增加RPC API暴露等等，但是在此之前它应该经过社区的测试。 自动执行一系列分散函数通常不是框架的责任。自动化应该通过API完成(查看Metasploit Community/Express/Pro, MSFGUI, 和Armiage).过去在框架自动化方面的努力证明了这一点。 像`db_autopwn` 和`browser_autopwn`,是很少用户期待的.通过越来越复杂的选项和参数来配置这些工具变成了一场噩梦。 自动化框架很容易，也应该保持简单，但是自动化本身应该存在于资源脚本和框架本身的其他外部前端。 控制台功能应该以漏洞利用和安全工具开发为重点，以漏洞利用开发者为典型用户。最终用户应该指向一个接口，如Community Edition或MSFGUI. 不要期望控制台的用户友好性。控制台应该被认为是Metasploit的调试模式，并尽可能接近裸机功能。 外部工具，例如msfpayload和msfvenom，旨在使exploit开发更容易和锻炼特定技术。我们将继续接受这种性质的工具以包含在框架中，但是这些工具应该附有文档，快速开始的指导教程以及其他有用的文本。