FTP程序安全嗎？

FTP的安全隱患及更安全的替代方案

關鍵要點:

• FTP程序（如FileZilla）可能隱藏密碼，但如果憑據被存儲，則很容易從配置文件中訪問，從而危及安全性。
• FTP本身缺乏安全性，以明文形式傳輸數據和憑據，容易被攔截和濫用。
• 安全的替代方案，如FTPS和SFTP，在傳輸過程中對數據進行加密，與傳統的FTP相比，提供了更高的安全級別。
• SSH密鑰通過無需傳輸敏感信息即可進行身份驗證來增強安全性，有效防止攔截。
• 持續交付工具和安全的FTP協議（如SFTP和FTPS）可以減輕手動文件傳輸過程中人為錯誤帶來的風險。

你是否使用FTP部署或傳輸文件？鑑於該協議的古老性和在眾多託管公司中的廣泛流行，可以說你可能正在使用。

但是，你是否意識到這可能會為你和你的企業帶來安全問題？讓我們深入探討一下這種情況。

FileZilla、CyberDuck、Transmit或Captain FTP等程序可以是安全的。它們可能實現一些措施，例如隱藏密碼，防止他人查看。但是，如果你使用FTP傳輸數據，這些措施實際上會被削弱。

我直截了當地說，我寫這篇文章的原因是8月份在SitePoint上進行的一次有趣的討論。討論主要集中在FileZilla上，對它有多不安全（或不是）做了一系列斷言。

爭論的一個關鍵方面集中在是否應該將密碼與FileZilla一起存儲。其中一條評論鏈接到一篇描述性文章，該文章表明，儘管在使用軟件時會隱藏你的憑據，但如果你保存了憑據，它們很容易被檢索。

如果你沒有讀過這篇文章，FileZilla會將連接詳細信息存儲在一個簡單的XML文件中，如下所示：

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><filezilla3></filezilla3>
    <servers></servers>
        <server></server>
            <host>localhost</host>
            <port>21</port>
            <protocol>0</protocol>
            <type>0</type>
            <user>anonymous</user>
            <pass>user</pass>
            <logontype>1</logontype>
            <timezoneoffset>0</timezoneoffset>
            <pasvmode>MODE_DEFAULT</pasvmode>
            <maximummultipleconnections>0</maximummultipleconnections>
            <encodingtype>Auto</encodingtype>
            <bypassproxy>0</bypassproxy>
            <name>test site</name>
            <comments> </comments>
            <localdir> </localdir>
            <remotedir> </remotedir>
            <syncbrowsing>0</syncbrowsing>test site
        >
    >
>

你可以看到它存儲了關於連接的大量信息，這樣你就不需要記住它了。但是請注意，它也以明文形式存儲你的密碼？

當然，當你使用該程序時，它會隱藏密碼，如上面的屏幕截圖所示，這樣就無法從你的肩膀上讀取。

但是，如果你可以訪問計算機，那麼從計算機中提取密碼就沒有意義了。公平地說，在最新版本的FileZilla中，默認情況下不允許存儲密碼。

加密配置文件怎麼樣？

有人建議，至少配置文件應該加密，或者以在授予訪問權限之前請求主密碼的方式設置，就像1Password和KeePassX一樣。

Louis Lazaris隨後鏈接到Stack Exchange上的一個討論，試圖反駁這一觀點。以下是這篇文章的核心內容：

你看，加密憑據需要一個加密密鑰，該密鑰需要存儲在某個地方。如果你的用戶帳戶上運行了惡意軟件，那麼他們和你（或任何其他在同一級別運行的應用程序）擁有的東西一樣多。這意味著他們也將能夠訪問加密密鑰或加密加密密鑰的密鑰等等。

我相信上述斷言並沒有完全理解1Password和KeePassX等程序的設計考慮。專門設計為密碼和其他安全信息的安全保管庫的應用程序，可能不像這個答案暗示的那樣容易破解。

例如，1Password最近的一篇博客文章列出了對抗黑客的關鍵機制。

這些包括128位和256位對稱密鑰、SHA512和PBKDF2加密——以及一系列其他用於保護被訪問的數據文件的特性，同時保留了它們易用性和簡單性。

因此，推斷使用安全的加密保管庫實際上並不更安全是不正確的，特別是考慮到所有這些可用的技術。

是FTP，而不是你的應用程序！

但是，關於是否應該保存憑據的論點是無關緊要的，因為使用FTP本身忽略了一個關鍵點——你的憑據和數據是以明文形式發送的。不相信我？請閱讀Deccanhosts博客上的《為什麼FTP不安全》。

如果你不知道，通過使用簡單的分組嗅探器，如Wireshark，你可以檢索到使用的用戶名和密碼，以及發送的文件中存儲的任何其他憑據，以及算法、數據庫結構以及存儲在其中的任何其他內容。

鑑於長期以來，將這些信息存儲在.ini和配置文件中是一種常見做法，我建議相當大量的易於下載的軟件，如WordPress、Joomla等，將以這種方式開發。

FTP的設計初衷並非為了安全性；它被設計為一項公共服務。這種設計中固有地包含了一系列進一步的假設，這些假設也沒有考慮到安全性。 Zend的高級軟件工程師Enrico Zimuel甚至說得更遠：永遠不要使用FTP——永遠！

是的，安全更改後來出現了，但它們是附加的——而不是內置的。沒有防止暴力攻擊的保護，雖然SSH隧道是可能的，但它很困難，因為你需要加密命令和數據通道。因此，你的選擇有限。當你試圖實現它們時，難度係數並不總是微不足道的。

你是一個網站管理員嗎？你是否為你的FTP用戶啟用了chroot監獄？如果你不熟悉chroot這個術語，它是一種限制用戶移動和訪問權限的方法。從他們登錄的目錄開始，他們可以進入任何子目錄，但不能移動到該目錄之外。

FTP的替代方案

在我讓你相信一切都糟透了之前——並非如此。今天周圍的一些FTP程序——特別是前面提到的那些程序——也支持一些更安全的FTP衍生產品和替代方案。讓我們來看看它們。

FTPS和SFTP

FTPS是安全FTP，就像HTTPS是安全HTTP一樣，它運行在SSL（安全套接字層）和TLS（傳輸層安全）之上。用戶憑據和數據不再以明文形式發送；而是先加密，然後再傳輸。

如果服務器允許，客戶端軟件還可以靈活地僅加密通信的一部分，而不是全部。根據目前的討論，這似乎違反直覺。

但是，如果被傳輸的文件已經被加密，或者沒有傳輸任何敏感性質的信息，那麼可能不需要承擔加密所需的開銷。

但是，切換到FTPS確實需要付出代價（和價格）。使用FTPS需要生成自簽名SSL證書，或從受信任的證書頒發機構購買證書。因此，更好的安全性是可用的，但是需要付出更多的努力和成本。

但在你退縮之前，問問自己，你的信息對你企業來說價值多少？這可能會說服你堅持下去。

現在讓我們看看SFTP。 SFTP或SSH文件傳輸協議的工作方式與FTPS不同。 SFTP被設計為SSH 2.0的擴展，它創建了一個普通的FTP連接，但在已經加密的連接上執行它。 FTP數據流本身並不比普通的FTP更安全，但是它運行的連接更安全。

SSH、SCP和其他登錄Shell

如果你要放棄FTP，為什麼要採取半途而廢的措施？為什麼要使用FTP？如果你安裝了SFTP，你就安裝了SSH工具；這些工具為你提供了各種各樣的功能。

從SSH本身開始，它為遠程系統提供了完整的用戶訪問權限，讓他們可以做比標準FTP更多的事情。連接是安全的，數據可以很容易地從一個系統複製到另一個系統。

如果你是一個命令行高手，你甚至可以使用SSH上的Rsync等工具。

在一個簡單的用例中，它可以用來將所有文件從本地目錄遞歸地複製到遠程計算機上的目錄。第一次運行時，所有文件都會被複製。

第二次及以後的運行，它會檢查文件差異，只傳輸差異、較新的文件，並可以選擇刪除遠程計算機上不再存在的本地文件和目錄。

問題是，授予這種訪問權限本身就是一個安全問題。但是效果是可以減輕的。 OpenSSH允許許多配置選擇，例如不允許root訪問、限制可以遠程登錄的用戶以及將用戶chroot到特定目錄。

也許用戶根本不需要在遠程計算機上，或者在他們在那裡時不需要很多權限。如果是這樣，並且很可能是這樣，你可以從許多旨在適應這些情況的shell中進行選擇。

最好的兩個是scponly和rssh。 Scponly只允許用戶將文件複製到遠程計算機。

用戶無法登錄、移動、查看或更改文件。好的是它仍然可以使用rsync（和其他工具）。 rssh更進一步，允許訪問SCP、SFTP、rdist、rsync和CVS。

要實現它，系統管理員只需使用他們選擇的工具更改用戶的shell，然後編輯/etc/rssh.conf，列出允許的協議。這是一個示例配置：

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><filezilla3></filezilla3>
    <servers></servers>
        <server></server>
            <host>localhost</host>
            <port>21</port>
            <protocol>0</protocol>
            <type>0</type>
            <user>anonymous</user>
            <pass>user</pass>
            <logontype>1</logontype>
            <timezoneoffset>0</timezoneoffset>
            <pasvmode>MODE_DEFAULT</pasvmode>
            <maximummultipleconnections>0</maximummultipleconnections>
            <encodingtype>Auto</encodingtype>
            <bypassproxy>0</bypassproxy>
            <name>test site</name>
            <comments> </comments>
            <localdir> </localdir>
            <remotedir> </remotedir>
            <syncbrowsing>0</syncbrowsing>test site
        >
    >
>

此配置僅允許用戶使用SCP和SFTP。

SSH密鑰

接下來，讓我們考慮SSH密鑰。這個過程需要一些解釋，但我將嘗試使其簡短扼要，大量改寫Stack Exchange上的這個答案：

首先，服務器的公鑰用於構建安全的SSH通道，方法是協商一個對稱密鑰，該密鑰將用於保護剩餘的會話，啟用通道機密性、完整性保護和服務器身份驗證。通道功能安全後，將進行用戶身份驗證。

接下來，服務器創建一個隨機值，用用戶的公鑰加密它並將其發送給他們。如果用戶是他們應該成為的用戶，他們可以解密挑戰並將其發送回服務器，然後服務器確認用戶的身份。這是經典的挑戰-響應模型。

這項技術的關鍵好處是私鑰永遠不會離開客戶端，也不會發送任何用戶名或密碼。如果有人攔截SSL流量，並且能夠解密它（使用被破壞的服務器私鑰，或者如果你在連接到服務器時接受錯誤的公鑰）——你的私人詳細信息將永遠不會落入攻擊者手中。

與SCP或SFTP一起使用時，這進一步減少了使用它們的所需工作量，同時提高了安全性。 SSH密鑰可能需要密碼來解鎖私鑰，這似乎會使它們更難使用。

但是，有一些工具可以將此鏈接到你的用戶會話，當你登錄到你的計算機時。正確設置後，密碼會自動為你提供，因此你可以充分利用該系統。

持續交付怎麼樣？

也許你以前沒有聽說過這個術語，但它已經存在一段時間了。我們之前在SitePoint上寫過關於它的文章，就在上週。由Martin Fowler創造的持續交付定義為：

一種軟件開發紀律，你以這樣一種方式構建軟件，即軟件可以隨時發佈到生產環境。

實現它的方法有很多，但是Codeship和Beanstalk等服務在很大程度上消除了痛苦。

以下是如何工作的粗略比喻。你設置你的軟件項目，包括你的測試代碼和部署腳本，並將所有這些存儲在版本控制下。我假設你正在使用在線服務，例如GitHub或Bitbucket。

在你的代碼分支中進行提交或發布後，每次向這些服務之一推送時，該服務都會運行你的應用程序的測試。如果測試通過，則會部署你的應用程序，無論是測試還是生產。

假設一切順利，它隨後會自動為你處理部署。之後你會收到通知，告知部署成功或失敗。

如果成功，你可以繼續下一個特性或錯誤修復。如果出現問題，你可以檢查它以查找問題的原因。請查看下面的簡短視頻，該視頻展示了使用Codeship實際部署測試存儲庫的過程。

你必須做什麼？將提交推送到Github存儲庫——就是這樣！你不需要記住運行腳本、腳本在哪裡、要傳遞給它們的選項和開關（尤其是在周五晚上很晚的時候，你寧願在任何地方而不是工作）。

我理解這相當簡單，並沒有涵蓋所有選項和細微之處，但你明白了我的意思。

人為錯誤的問題

最後，讓我們從使用FTP的基本安全問題轉向日常使用的有效性。例如，假設你正在開發一個網站，例如一個電子商務商店，並且你的部署過程使用FTP，特別是FileZilla。

這裡有一些與人為錯誤相關的固有問題：

• 所有文件是否都上傳到正確的 位置？
• 文件是否保留或獲得所需的權限？
• 是否會忘記一兩個文件？
• 生產中是否需要更改一個開發名稱？
• 是否需要運行部署後腳本？

所有這些都是有效的擔憂，但是當使用持續交付工具時，所有這些都可以很容易地減輕。如果時間晚了，如果壓力很大，如果相關人員即將離開公司或渴望休假，那麼通過FTP手動傳輸文件就是在自找麻煩。

好吧，手動傳輸文件，總而言之，就是在自找麻煩。人為錯誤太難避免了。

向FileZilla致歉

我不想顯得好像我是在針對FileZilla。它是一個非常好的應用程序，我已經使用了多年。並且已經使用了試圖使其更安全的技術。

我的關鍵點在於FTP本身，而不是僅僅是FileZilla。

總結

這就是我對FTP安全辯論的看法。我的建議——不要使用它；此外，在管理部署時，請記住安全性。畢竟，這是你的數據。

但是你的想法是什麼？你還在使用FTP嗎？你是否考慮過遷移？在評論中分享你的經驗以及你嘗試過的解決方案，這樣我們都可以努力尋找一個實用且易於使用的解決方案。

進一步閱讀和資源

• ZendCryptPassword
• 密碼（不）安全性（幻燈片）
• 為什麼FTP不安全
• Wireshark（網絡協議分析器）
• 1Password 4中不斷發展的安全
• 當心：FileZilla無法保護你的密碼
• Linux受限Shell：rssh和scponly

關於FTP程序安全的常見問題

與FTP程序相關的安全風險主要有哪些？

FTP程序雖然對文件傳輸很有用，但也存在一些安全風險。主要問題是FTP不加密數據，這意味著所有傳輸的信息，包括敏感數據（如用戶名和密碼），都是以明文形式發送的。這使得網絡罪犯很容易攔截和濫用這些信息。此外，FTP容易受到暴力攻擊、數據包捕獲和欺騙攻擊等攻擊。這些風險可能導致數據洩露、未經授權的訪問和其他嚴重的安全問題。

如何減輕使用FTP程序的風險？

有幾種方法可以減輕與FTP程序相關的風險。最有效的方法之一是使用FTP的安全版本，例如SFTP或FTPS。這些協議在傳輸過程中加密數據，使網絡罪犯難以攔截。此外，使用強壯、唯一的密碼並定期更新它們可以幫助防止暴力攻擊。保持FTP程序更新也很重要，因為更新通常包含安全補丁。

FTP、SFTP和FTPS之間有什麼區別？

FTP或文件傳輸協議是一種標準的網絡協議，用於通過互聯網將文件從一台主機傳輸到另一台主機。但是，它不提供任何加密。 SFTP或安全文件傳輸協議是FTP的安全版本，它使用SSH（安全外殼）在傳輸過程中加密數據。 FTPS或FTP Secure是FTP的另一個安全版本，它使用SSL（安全套接字層）或TLS（傳輸層安全）進行加密。

今天仍然使用FTP嗎？

是的，FTP今天仍然被廣泛使用，尤其是在企業環境中用於傳輸大型文件或批量文件。但是，由於其安全漏洞，許多組織正在轉向更安全的替代方案，如SFTP或FTPS。

如何判斷我的FTP程序是否安全？

要確定你的FTP程序是否安全，你應該檢查它是否在文件傳輸過程中使用加密。 FTP的安全版本，如SFTP和FTPS，在傳輸過程中加密數據。你通常可以在程序的文檔或設置中找到此信息。此外，安全的FTP程序應該提供諸如強密碼強制、雙因素身份驗證和定期更新等功能。

我可以將VPN與FTP程序一起使用來增強安全性嗎？

是的，將VPN（虛擬專用網絡）與FTP程序一起使用可以增強安全性。 VPN加密通過互聯網發送的所有數據，包括你的FTP流量。這可以幫助保護你的數據不被網絡罪犯攔截。

FTP的一些安全替代方案是什麼？

FTP的一些安全替代方案包括SFTP、FTPS和SCP（安全複製協議）。這些協議都使用加密來保護傳輸過程中的數據。此外，基於雲的文件傳輸服務通常提供強大的安全措施，包括加密、雙因素身份驗證和訪問控制。

什麼是暴力攻擊，它如何影響FTP？

暴力攻擊是一種網絡攻擊，攻擊者試圖通過猜測密碼來訪問系統。由於FTP以明文形式發送密碼，因此它特別容易受到暴力攻擊。如果攻擊者成功猜測到密碼，他們可以未經授權訪問系統，並可能竊取或操縱數據。

如何保護我的FTP程序免受欺騙攻擊？

欺騙攻擊（攻擊者假裝是合法用戶或設備）可能是對FTP程序的嚴重威脅。為了防止這些攻擊，你可以使用使用加密的FTP的安全版本，如SFTP或FTPS。此外，使用強壯、唯一的密碼並定期更新它們可以幫助防止欺騙攻擊。

什麼是數據包捕獲，它如何影響FTP？

數據包捕獲，也稱為數據包嗅探，是網絡罪犯用來攔截和分析數據包在網絡上傳輸時的方法。由於FTP不加密數據，因此它特別容易受到數據包捕獲的影響。攻擊者可以使用此方法竊取敏感信息，如用戶名和密碼。為了防止數據包捕獲，你應該使用使用加密的FTP的安全版本，如SFTP或FTPS。

以上是FTP程序安全嗎？的詳細內容。更多資訊請關注PHP中文網其他相關文章！