簡介
FTP協議簡介
轉發控制連接
FTP
防火牆和被動模式
FTP和網絡地址轉換(Network Address Translation)
客戶端網絡地址轉換問題
服務器端網絡地址轉換問題
使用默認數據傳輸端口
轉發數據連接
結論
簡介
有關SSH
一個經常被問起的問題是
我怎樣才能使用端口轉發加強FTP安全?
很不幸
你得到的回答一般非常簡短
讓你仍然無所適從
在標准FTP協議中
所有的數據都是明文傳輸的
因此網絡上可能存在的嗅探器是一個極大的威脅
使用嗅探器
攻擊者很容易獲得你的帳戶和密碼
而在SSH的數據傳輸過程中
所有的數據以密文的形式傳輸的
所以SSH的端口轉發功能能夠很好地保護的帳戶密碼
本文詳細地解釋你能夠使用SSH和FTP做什麼
不能做什麼
以及其原因
這裡有FTP本身的復雜性造成的問題
除此之外
防火牆和網絡地址轉換(Network Address Translation)也給我們制造了不少困難
因為現在防火牆和網絡地址轉換(Network Address Translation)已經廣泛存在了
因此我們將對這些情況進行詳細的討論
不過
由於網絡環境千差萬別
我們無法覆蓋所有可能出現的問題
這就需要你自己舉一反三了
FTP協議簡介
為了便於後面的討論
我們首先簡要地討論一下FTP協議(如果對FTP協議已經有了比較深入的了解
你可以略過這一節)
大多數的TCP服務是使用單個的連接
一般是客戶向服務器的一個周知端口發起連接
然後使用這個連接進行通訊
但是
FTP協議卻有所不同
它使用雙向的多個連接
而且使用的端口很難預計
一般
FTP連接包括
一個控制連接(control connection)
這個連接用於傳遞客戶端的命令和服務器端對命令的響應
它使用服務器的
端口
生存期是整個FTP會話時間
幾個數據連接(data connection)
這些連接用於傳輸文件和其它數據
例如
目錄列表等
這種連接在需要數據傳輸時建立
而一旦數據傳輸完畢就關閉
每次使用的端口也不一定相同
而且
數據連接既可能是客戶端發起的
也可能是服務器端發起的
下面
我們通過一個FTP客戶程序看一下控制連接
這裡
我們需要使用debug模式(ftp
d)才能顯示客戶發出的FTP協議命令
在客戶程序的輸出信息中
這些協議命令是以
>開頭的
例如
> USER nixe
n
在命令發出之後
服務器會發出響應
響應信息以數字開頭
例如
Login incorrect
下面
我們和FTP服務器建立一個連接
使用用戶名nixe
n登錄
在會話過程中發出兩次目錄切換名
一次成功一次失敗
其中黑體是我們的輸入
ftp
d
Connected to
FTP server ready
Name (:nixe
n): nixe
n
> USER nixe
n
Password required for nixe
n
Password:
> PASS XXXX
User nixe
n logged in
> SYST
UNIX Type: L
Remote system type is UNIX
Using binary mode to transfer files
ftp> cd one
> CWD one
CWD command successful
ftp> cd tmp
> CWD tmp
tmp: No such file or directory
ftp> bye
> QUIT
You have transferred
bytes in
files
Total traffic for this session was
bytes in
transfers
Thank you for using the FTP service on
在FTP協議中
控制連接使用周知端口
因此使用SSH的標准端口轉發就可以這種連接進行很好的安全保護
相反
數據傳輸連接的目的端口通常實現無法知道
因此處理這樣的端口轉發非常困難
FTP協議使用一個標准的端口
作為ftp
data端口
但是這個端口只用於連接的源地址是服務器端的情況
在這個端口上根本就沒有監聽進程
FTP的數據連接和控制連接的方向一般是相反的
也就是說
是服務器向客戶端發起一個用於數據傳輸的連接
連接的端口是由服務器端和客戶端協商確定的
FTP協議的這個特征對SSH轉發以及防火牆和NAT的配置增加了很多困難
除此之外
還有另外一種FTP模式
叫做被動模式(passive mod)
在這種模式下
數據連接是由客戶程序發起的
和剛才討論過的模式(我們可以叫做主動模式)相反
是否采取被動模式取決於客戶程序
在ftp命令行中使用passive命令就可以關閉/打開被動模式
在了解了使用SSH轉發FTP連接的一些難點之後
我們將開始討論如何解決這些問題
轉發控制連接
FTP的控制連接的一端是一個周知端口
因此很容易通過SSH實現端口的轉發
通常
需要保護的FTP服務器上需要運行SSH服務
而且你需要在服務器上有一個合法帳戶以便通過SSH訪問FTP服務
假設你已經登錄到一台主機名為client的客戶主機
然後想通過安全的連接登錄到FTP服務器
要轉發FTP控制連接
首先要在client上運行一個SSH端口轉發命令
[nixe
n@client nixe
n]ssh
L
::
nix
cn
s password:
接著
就可以使用被轉發的端口登錄到
[nixe
n@clinet nixe
n]ftp localhost
Connected to localhost
FTP server ready
Name:foo
Password:
User foo logged in
ftp>
這裡
我們需要注意兩個非常重要的問題
在本地進行轉發
可能出現一些錯誤
在確定轉發的目標時
建議不要使用localhost作為目標
因為有時使用這種地址可能出現一些莫名其妙的問題
假如在你的主機(client)上
有其它的網絡接口(例如
eth
)
其地址為
如果你想在本機上進行SSH進行FTP端口轉發
[nixe
n@localhost nixe
n]$ssh
L
:localhost:
localhost
nixe
n@localhost
s password:
然後
使用ftp命令登錄到FTP服務器就可能出現一些錯誤
[nixe
n@localhost nixe
n]ftp localhost
Connected to localhost
localhost FTP server ready
Name[localhost:nixe
n]:nixe
n
Password required for nixe
n
Password:
User nixe
n logged in
ftp>ls
PORT command successful
Can
t build data connection:Cannot assign requested address
ftp>
出現這個問題是因為FTP服務器會試圖通過回環地址(lo:
)向client(eth
:
)發起連接造成的
本機的回環接口只能和本機的其它回環接口進行通訊
如果和其它的網絡接口(例如
eth
)通訊
就會返回
address not available
的錯誤
客戶程序需要使用被動模式
被動模式對於解決NAT/防火牆造成的一些問題很有幫助
Linux系統的ftp命令在默認情況下使用這種模式
FTP
防火牆和被動模式
前面我們講過
FTP協議的數據傳輸存在兩種模式
主動模式和被動模式
這兩種模式發起連接的方向截然相反
主動模式是從服務器端向客戶端發起
被動模式是客戶端向服務器端發起連接
但是如果服務器和客戶之間存在防火牆
主動模式經常會引起一些麻煩
設想
客戶位於防火牆之後
防火牆允許所有內部向外部的連接通過
但是對於外部向內部發起的連接卻存在很多限制
在這種情況下
客戶可以正常地和服務器建立控制連接
而如果使用主動模式
ls
put和get等數據傳輸命令就很難成功運行
因為防火牆會阻塞從服務器向客戶發起的數據傳輸連接
簡單包過濾防火牆把控制連接和數據傳輸連接完全分離開了
因此很難通過配置防火牆允許主動模式的FTP數據傳輸連接通過
如果防火牆允許ICMP或者TCP RST報文通過
客戶程序就會馬上返回connection refused錯誤信息
而如果防火牆只是做簡單的丟棄處理
會造成客戶程序掛起一段時間
被動模式一般可以解決此類問題
因為在被動模式下
連接是由客戶端發起的餓
不過
這要看FTP服務器和客戶程序是否支持被動模式
命令行FTP客戶程序一般使用passive命令關/開被動模式
例如
ftp>passive
Passive mode off
ftp>passive
Passive mode on
如果客戶程序不支持被動模式
它就會返回?Invaild command
如果客戶程序支持被動模式
而服務器不支持
就會返回
PASV:command not understood
PASV是一個FTP協議命令
使服務器進入到被動模式
FTP和網絡地址轉換(Network Address Translation)
除了簡單包過濾防火牆之外
被動模式也可以解決使用網絡地址轉換(NAT)給FTP造成的一些問題
在轉發報文之前
進行網絡地址轉換的網關首先會改變報文的源地址和目的地址
網絡地址轉換能夠提高網絡的安全性
有助於解決IP地址資源不足問題
客戶端網絡地址轉換問題
假設你的FTP客戶主機位於局域網內
通過一個網絡地址轉換(NAT)網關連入互聯網
在這種情況下
客戶程序可以毫無困難地和外部的FTP服務器建立控制連接
但是
如果
From:http://tw.wingwit.com/Article/program/Oracle/201311/17826.html