扭曲的Telnet服務器：如何避免嵌套的CRLF

我正在實現一個Telnet服務器，我有兩個Telnet實現：預認證和後驗證。扭曲的Telnet服務器：如何避免嵌套的CRLF

核心問題是服務器發送\r\r\n而不是\r\n。通過一步調試，我發現這是由於ProtocolTransportMixin，這是類在heriarchy有兩次。我相信這是由於pre-auth和post-auth運輸之間存在某種相互聯繫（一個是另一個的基本運輸）。

有沒有辦法可以取消mixin的效果？

我的Telnet服務器工廠實例與

lambda: TelnetTransport(MyOwnTelnetAuthTransport, ...)

MyOwnTelnetAuthTransport是AuthenticatingTelnetProtocol一個子類。

後驗證，我通過我自己的子類TelnetBootstrapProtocol通過領域連接它。

由於兩個TelnetTransport和TelnetBootstrapProtocol具有在其write()方法我結束了\r\r\n替代\n爲\r\n的ProtocolTransportMixin ...

來源

2016-01-29 Olivier Bilodeau

我有那種黑客攻擊的固定它。仍在尋找更好的解決方案。

子類TelnetTransport與MyTelnet具有以下實現：

class MyTelnet(TelnetTransport): 
    """Sole purpose is to override write() and fix a CRLF nesting bug""" 

    # Because of the presence of two ProtocolTransportMixin in the protocol 
    # stack once authenticated, I need to override write() and remove a \r 
    # otherwise we end up with \r\r\n on the wire. 
    def write(self, bytes): 
     self.transport.write(bytes.replace('\r\n', '\n'))

然後調整我廠產卵這個類，而不是TelnetTransport固定它。

來源

2016-01-29 17:27:53

雖然這看起來會工作99.9％的時間，但從技術上講，這是不正確的，因爲調用者*可能*調用'write（「\ r」）'然後'write（「\ n」）''。 – Glyph

首先，如果您實際上對用戶進行身份驗證，請勿使用telnet。使用SSH。 Twisted提供了conch，它已經實現了該協議。

其次，當你問這樣的問題時，請始終提供一個SSCCE。我不知道你的實際問題是什麼，除非我可以運行你的代碼，而且我不打算基於鬆散的描述來重建你的代碼。

最後，雖然聽起來好像你剛纔在Twisted中發現了一個bug，你應該把它歸檔。 TelnetTransport不應該在CR s上加倍，所以如果確實發生了這種情況，它不應該是代碼中的一種蠻幹解決方法，而應該是上游的修復。

P.S .: MyOwnTelnetAuthTransport不是運輸工具，它是TelnetProtocol，所以命名有點混亂。如果你把Transport類放在它的層次結構中，也許這就是問題所在？

來源

2016-01-29 22:19:21 Glyph

蜜罐在互聯網上捕獲惡意軟件。我明確地對基於扭曲的SSH蜜罐實施了Telnet身份驗證，因此它可以具有更多的覆蓋範圍。 –

我希望提供一個SSCCE，但它涉及到一個Portal，一個Avatar，Telnet協議，工廠，認證類，然後掛鉤到終端（History.Recvline或其他）......我可能會回來提供它，但它是一個不平凡的工作量。我想提供我的項目，以便我可以繼續工作：惡意軟件分析。這是一個黑客，但它的工作，所以SSCCE的激勵下降了很多。這PR可以讓你知道我做了什麼：https://github.com/micheloosterhof/cowrie/compare/master...GoSecure:telnet-wip?expand=1 –

解決PS：我發現框架並不清楚運輸和協議之間的區別。在過去的幾周裏，我已經閱讀了很多扭曲的文檔和源代碼，因爲我正在實施這個過程，而且在Telnet環境中我仍然不清楚。我可能混合了這兩種。我一定會重新命名班級來表達正確的意圖。謝謝！ –

扭曲的Telnet服務器：如何避免嵌套的CRLF

回答

相關問題