RMRUG ♡ VICKI - Blog

前一篇IPSec並無分享真實運作的情況

這些畫面將在此篇補上


今天又麻煩我老大幫我測試啦~ (感謝老婆大人)
這是把大部分的畫面都節錄下來了

首先我們先了解一下我跟我老大使用的IP Address

我：118.xxx.xxx.216 (有部份畫面因為沒處理好，所以看起來像118.xxx.xxx.6)
我老大：220.xxx.xxx.218

接下來我們先看看進行MSN文字訊息交換的狀況

(點圖以放到最大)

可以發現我老大傳送給我的MSN訊息封包並非從她的IP直接傳送過來
而是經過207.46.27.38這台MSN Server轉送，所以是無法加密的
中間直接分析封包可以看見我老大傳給我的「hello」字串
這驗證了，如果不使用第三方軟體，想靠IPSec加密MSN無法辦到
除非可以強迫MSN進行點對點傳送文字訊息


接下來我們驗證是否真的再每個傳輸初始化時會進行ISAKMP來請求使用IPSec

(點圖以放到最大)

我直接使用filter把ISAKMP抓出來，果然很多，證明了IPSec確實在運作於每個連線
可從Destination看出我傳送給跟我傳輸的主機ISAKMP，來要求IPSec
只是對方都不支援，所以會放棄使用IPSec
(一般沒啟動IPSec或沒設定正確，應該是抓不到這樣的封包的)

接著我請我老大傳送遠端協助(Remote Assistance)邀請函給我
我開啟邀請函打入密碼前，開始捕抓封包，並且啟動邀請，看到如下圖所示狀況

(點圖以放到最大)

很明顯的，直接使用了ESP封包，其他人就算擷取了封包，也是完全看不懂阿
連我們用什麼東西交換資訊，封包類型都看不出來了，我不說是遠端協助也沒人知道
但是看倌們一定有疑問，IPSec不是應該會先丟ISAKMP等雙方協調好才開始ESP嗎!?
沒錯的，不過因為剛剛在使用MSN的時候，已經有協調完成了
這時候又會冒出另一個問題，剛剛又說MSN會經過MSN Server，不能用IPSec?
這也沒錯的，但是MSN在某些特殊的封包是會進行點對點傳送的
所以在MSN聊天的同時，也會跟對方IP做直接的接觸，觸發了IPSec
不過很可惜的，這些在進行交換IPSec資訊的封包我沒有抓到

我們也可以從IPSec狀態來檢查看看是不是真的啟動了IPSec加密，如下如所示

(點圖以放到最大)

我們可以看到，連168.95.1.1這台可憐的Hinet DNS都被我要求ISAKMP
不過這台主機當然不支援IPSec(就算支援也不知道我加密的字串是什麼)
故所有的驗證加密都是「<無>」，接著我們看到我老大的IP
後面ESP機密欄位是3DES，ESP整合採用SHA1，證明了我跟我老大之間的任何傳輸
只要是TCP/UDP(我設定套用在這兩個協定上)，就會被ESP加密

那我們最後再來看看，如果沒有ESP的狀況之下的通訊是如何的
同樣的使用遠端協助(Remote Assistance)，我把我的IPSec Policy改為不指派
並且重新啟動IPSec Service，接下來檢查IPSec狀態，是淨空的，沒有任何啟用的Policy
接下來我請我老大重新製作一份邀請給我，我同樣的在打開邀請前開始捕抓封包
可以看到如下圖所示

(點圖以放到最大)

很明顯的，從第五個封包看出開始進行連線交換，全部都是明文
若有心人士想從中抓取資料是不無可能的，證明了沒有使用IPSec的狀態下
所有封包在網路上流竄時都是赤裸裸的待宰羔羊
當然一般來說是不可能有這種狀況，除非從Router下手，但是在區域網路環境
這些問題就會變的很明顯，IPSec在區域網路環境大致上可以提供比較安全的管道
前提是兩方都要支援IPSec


以上就是IPSec所有報告!

相關閱讀：
IPSec　by Rmrug
IPSec實作　by Rmrug


PS.如果這系列的實作有幫助到您，或有疑問，歡迎留言討論