> 注意　Metasploit Redmine已經關閉　官方wiki沒有更新 ### Metasploit bug 提交 任何開源軟件產品越來越受歡迎，有一種趨勢是看到bug報告量的增加以及bug報告質量的相應降低。 我們不反對為Metasploit提交錯誤報告 - 我們需要錯誤報告來了解什么是壞的，而不是試圖阻止bug的浪潮 所以，這個頁面不是試圖阻止錯誤的浪潮，而是試圖確保我們得到的每個錯誤報告都是以最大化解決問題的機會來寫的。這個頁面將試圖確保我們得到的每個錯誤報告都是以最大化實際得到解決問題的機會的目的寫成的。 對于這一點 metasploit社區是閱讀了數千份bug報告。事實證明，編寫良好的錯誤報告可以更快，更輕松地修復這些錯誤。 真正相當了不起的是，快速的關閉時間似乎與錯誤報告質量密切相關，而不是錯誤本身的復雜性。 相當驚人的是，快速的bug關閉時間似乎與錯誤報告質量密切相關，而不是錯誤本身的復雜性。 有兩種情況你一般不應該打開一個bug報告，那就是當你有一份支持合同，或者當你發現Metasploit本身存在一個安全問題的時候。 #### 支持合同 如果您有Metasploit產品的支持合同，您應該聯系您的Rapid7支持代表，或致信support@rapid7.com。 Metasploit支持全職工作的人真的很`漂亮`， 它可能當場有一個修補程序或解決方法 #### 安全問題 如果你發現Metasploit本身存在安全問題，那么如果您通過`security@metasploit.com`告訴我們，我們將非常感激。畢竟，我們希望得到和其他軟件項目一樣的對待。并不是說，我們想要掩蓋你的bug報告.而是想在有人開始擾亂我們的無辜用戶之前，試著修復bug。 我們很樂意為您提供信任，讓您匿名，告知您進展情況，并與您探討相關問題 。但是如果我們看到有人公開報告安全漏洞，那么就很難保持要所有的歸屬和直接溝通，因為我們要盡最大努力盡可能快地修復漏洞。 另外，如果你可以以Metasploit模塊的模式發送給security@metasploit.com的報告你的安全漏洞，那么這將是理想和歡慶的。 這應該包括你根本不應該打開一個bug報告的情況，所以讓我們繼續我們的主要問題跟蹤系統，`Redmine` ### 介紹 Redmine Metasploit中bug報告的最終目的地是我們的Redmine問題跟蹤器。這就是我們想追蹤的所有問題誕生，變老，最終死亡的地方。 為了提交錯誤報告，您必須先創建一個帳戶。 這很容易，也很有趣。可悲的是，由于垃圾郵件的問題，目前我們不能采取真正的匿名漏洞報告，但是我們正在積極探索如何使這種注冊盡可能人性化和簡單。 在談到Metasploit時，有人問道：“有沒有bug？。或者是指“bug追蹤器”或“Redmine"，但我們幾乎總是在談論這個系統。 #### 它們都是bug 談到對話，重要的是要注意，我們傾向于將所有問題稱為“bug”，而不管它是缺陷，功能請求或支持請求。 這只是少數音節和字符的區別，并不意味著貶低這個問題的內容 #### github issues 我們在GitHub倉庫中啟用了一個問題跟蹤器，但是，正如上面所說的，如果它們要被跟蹤的話，BUG應該會在Redmine上。 我們有一個幻想關閉Redmine一段時間，完全切換到GitHub的`issues`，但Redmine仍然是對于放棄來說是有用的。 因此，在此期間，沒有人會阻止您提交GitHub問題。 許多GitHub項目都有一個“問題”按鈕，我們寧愿不讓人們感到驚訝，并通過wiki學會出如何報告錯誤。 如果你正在閱讀這個，現在你已經明白了，所以應該避免這個`issues`標簽。 #### 電子郵件 我們維護幾個郵件列表 - [Metasploit框架](https://dev.metasploit.com/mailman/listinfo/framework)和[Metasploit-Hackers列表](https://lists.sourceforge.net/lists/listinfo/metasploit-hackers)。有時候人們會遇到問題，他們會在那里提到他們。有時，有人會根據這些列表上的流量匯總錯誤報告，但有時候沒有人會這樣做。重點是，如果您不確定是否有錯誤或僅僅是使用問題，請以一封郵件到框架的郵件列表開始。如果你確定你有一個bug，那么最好從一個普通的錯誤報告開始，然后在其中一個郵件列表中提到它。 #### Rapid7社區 Rapid7在(它是等待的)[community.rapid7.com](community.rapid7.com)上運行Metasploit用戶社區。就像電子郵件一樣，這里主要是討論和幫助使用Metasploit的場所，而不是那么多的bug報告。 ### 入門 在bug報告的機制上，足夠的談論 #### 避免重復 你可能不是第一個注意到你遇到的問題的人，所以這里有一些策略來確保以前報告的錯誤被關注。 如果您遇到特定模塊的問題，可以嘗試搜索該模塊的名稱來查看是否已經有任何已報告的內容。如果你的bug有一個特定的錯誤信息，那就去搜索那個。 另一個策略是簡單地瀏覽最近的錯誤，特別是如果你懷疑這個過程中有一個新的錯誤，因為你以前肯定會使用過它。 如果您碰巧發現了您遇到的錯誤，那么使用任何新信息更新報告對于解決問題都是非常有幫助的。你也可以找到解決的錯誤，描述你的問題，這表明一個回歸（老bug重新引入） - 修復這些問題通常是快速的，所以注意到可能的問題回歸是相當有用的。 最后，你可能會發現一個被拒絕或關閉的錯誤。在這些情況下，這個問題通常是Metasploit外部的東西 - 用戶錯誤，配置怪異，已知的不兼容性等等。如果您認為原來決定錯誤，請打開一個新的bug并指出您認為的問題是什么。畢竟，如果人們繼續碰到同一個非bug，那么這可能至少是一個文檔bug，也可能是真的。 ### 描述你的錯誤 #### 讓你的bug可搜索 由于我們在提交之前談論了尋找已有bug報告的重要性，所以確保你的bug是可以找到的。在標題中使用特定的模塊名稱和錯誤消息，并盡可能多地包含報告中的錯誤。"The Windows login aux mod is broken”是一個可怕的標題，而“NoMethodError raised on smb_login module”好得多。 大多數情況下，你遇到的錯誤沒有很好，清楚的錯誤信息。在這些情況下，試著確定標題中的內容。例如，請查看錯誤 #7215 這是一個非常典型的投訴，一些模塊未能打開一個shell，但注意到，雖然模塊名稱不在標題中，但是在開始描述中。此外，這個錯誤有很多日志和屏幕截圖。 #### 日志和屏幕截圖 查看Bug＃6905。如果我們所有的錯誤報告都是這樣的話，我會很高興的。它非常簡短，并具有一切基礎 - 一個簡短但描述性的標題，錯誤的完整回溯，完整的歷史記錄以及版本信息。這個bug非常適合搜索，也容易重現。 如果您正在實驗室或虛擬環境中測試模塊，我們希望獲得盡可能多的目標數據。這意味著包括精確到補丁級別的目標的準確版本，如果可以的話，捕獲它們的pcaps，以及Framework內部或外部的任何類型的日志記錄。 通常情況下，我們會要求framework.log- 通常保存在那里`$HOME/.msf4/framework.log`。 另一方面，如果您在一個協議內時遇到問題，我們知道您不能在您的錯誤報告中包含一堆客戶數據。在這種情況下，我們仍然會在日志中發現錯誤，但是您需要首先對它們進行清理，如果您需要拒絕，我們不會感覺受到傷害。這就是對一個公司滲透測試的業務。 #### 提到你的環境 這可能是你所描述的錯誤只會在你的環境中出現。如果你不在正常的Metasploit開發環境或者Metasploit安裝中，你要在你的bug報告中特別提到這一點。命令的輸出ruby -v和 uname -a（或winver）通常非常有幫助。 #### 包括重現的步驟 至少，你的狀態采取的步驟可能在這里找到`$HOME/.msf4/history,`，所以您可以從那里剪切和粘貼。如果比命令歷史記錄中包含的背景信息更多，比如可能使用的有趣的網絡配置，那么也要提到這一點。 我們喜歡可用于可靠觸發bug的資源腳本（rc腳本）。這些腳本最終可以找到可重復的測試用例，所以如果你能把它們放在一起，太棒了！有關資源腳本編寫的更多信息，請參閱[此博客文章](https://community.rapid7.com/community/metasploit/blog/2010/03/22/automating-the-metasploit-console)。 ### 補丁 #### 提供補丁 也許你遇到了一個bug，而且你已經知道如何修復它了。或者，你只是在互聯網上的想要幫助誰的一個友善陌生人。 使得補丁到Metasploit最可靠的方法是修補你自己的分叉，并以我們的方式提出[pull請求](https://github.com/rapid7/metasploit-framework/wiki/Metasploit-Development-Environment#wiki-pull)。 既然你攻擊了一個已經存在的bug，你可以使用[SeeRM＃1234]或者[FixRM＃1234]的一個特殊的提交信息字符串，并且會自動更新Redmine的指針， 一旦修復完成,由于它是人類可讀的，所以我們可以立即告訴你,你正在談論一個Redmine問題，所以你或者某人可以通過指向你的pull requestr的鏈接來更新Redmine。 當然，這一切都假定你已經迷上了GitHub。如果這對你不起作用，你可以通過簡單地創建一個補丁`diff`來對最近的Metasploit進行`checkout`，從而將補丁附加到Redmine問題上 - 對于大多數SVN用戶來說，情況就是這樣（在這種情況下，你會想使用svn diff） 現在，應該預先警告：直接提交給Redmine的補丁比較麻煩，特別是如果有更多的問題。如果你打算修補不止一次或兩次，那么你花一點時間建立你的Metasploit開發環境，并開始在自己環境玩。 #### 提供測試案例 我們喜歡 , 不. 愛進行測試，來顯示補丁實際上工作。同樣，資源腳本是快速組合的好方法，您可以將其與標準實用程序`screen`結合使用以獲得一些出色的決議： * 打開screen并按Ctrl-a H　 * msfconsole -L -q -r /path/to/your/test.rc * 退出msfconsole和git checkout分支包含修復程序 * msfconsole -L -q -r /path/to/your/test.rc * 退出離開screen 這將生成一個包含所有輸出和所有擊鍵的修復的屏幕日志。是的，它會看起來在一個普通的文本編輯器，可怕的是由于各種轉義碼，但cat并less都解決這些綽綽有余。 如果你在Windows上，msfconsole spool命令應該提供足夠的輸出，至少演示問題及其解決方案。 ### 跟進bug 所以，你要盡全力去編寫一個bug報告，并且要確保它得到解決。接下來是什么？ #### 通知設置 如果你在Redmine上打開了一個bug，你應該自動通過電子郵件獲得更新，而GitHub pull請求也是如此。如果您不是由于某種原因，您應該檢查自己的垃圾郵件過濾器以及通知設置。如果你想追蹤一些你尚未涉及到的bug，你可以隨時在任何問題的右上方勾選“Watch”star，每當它發生變化時，你都會得到更新。 TODO：將Redmine更新掛鉤到已經在觀看的GitHub的Metasploit-Notifications。這將需要十分鐘。 #### 解決錯誤 [Metasploit-Framework master分支](https://github.com/rapid7/metasploit-framework)有一個修復程序后，您的bug應該被視為“已解決” 。跟蹤該分支的人當然會立即得到修復。幾分鐘后，依靠`msfupdate`SVN的每個人都可以訪問修復程序。這些是最先進的分支。 每周一次（通常是星期三），我們發布Metasploit下載的更新。一般來說，Metasploit框架修復將在適當的QA之后每周進行一次安裝。所以，雖然我們可能會將錯誤稱為“已解決”，但可能還不能獲得。