### 接受指南 由于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開發更容易和鍛煉特定技術。我們將繼續接受這種性質的工具以包含在框架中，但是這些工具應該附有文檔，快速開始的指導教程以及其他有用的文本。