突發(fā)奇想

相信“陽康”的小伙伴居家辦公的場景還歷歷在目，那VPN想必大家一定不會陌生，那不知道大家會不會有這么一個疑問，VPN服務(wù)端與客戶端的流量傳輸是否真的安全的？那剛好我有一個朋友想知道連著公司VPN一邊工作一邊摸魚會不會被發(fā)現(xiàn)？于是帶著這個疑問開展了對于VPN服務(wù)端與客戶端之間的流量傳輸?shù)臏y試。

說干就干

此次模擬仿真服務(wù)為OpenVPN服務(wù)，核心技術(shù)是虛擬網(wǎng)卡和加密傳輸，OpenVPN是一個全特性的SSL VPN，它使用2層或3層的安全網(wǎng)絡(luò)技術(shù)，標準的SSL/TLS協(xié)議，也是目前最接近商用VPN的開源解決方案。

仿真環(huán)境準備（局域網(wǎng)搭建環(huán)境）：

openvpn服務(wù)端IP：199.166.1.215

openvpn客戶端IP：199.166.1.141

訪問工作網(wǎng)站IP：http://199.166.1.202:7002

訪問控制規(guī)則：禁止openvpn客戶端到訪問目標的流量

VPN客戶端

1、客戶端導入VPN認證證書，通過賬戶認證，連接VPN服務(wù)。此時客戶端主機會創(chuàng)建一個虛擬網(wǎng)卡，依據(jù)配置文件分配虛擬網(wǎng)卡一個虛擬IP：10.8.0.6，那此時客戶端主機將存在雙網(wǎng)卡，一張主機物理網(wǎng)卡（en0）以及一張TUN虛擬網(wǎng)卡（utun3）。

ifconfigen0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 199.1.1.141 netmask 0xffffff00 broadcast 199.1.1.255nd6 options=201<PERFORMNUD,DAD>media: autoselectstatus: activeutun3: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500inet 10.8.0.6 --> 10.8.0.5 netmask 0xfffffffc

模擬工作時的場景，用戶連接VPN，訪問工作網(wǎng)站，通過wireshark分別抓取客戶端主機物理網(wǎng)卡以及TUN虛擬網(wǎng)卡的流量，對流量包進行審計：

（1）主機物理網(wǎng)卡抓取流量中未發(fā)現(xiàn)本機直接訪問工作網(wǎng)站的流量，說明訪問目標網(wǎng)站的流量并未經(jīng)過物理網(wǎng)卡直接進行傳輸，于是對虛擬網(wǎng)卡的流量進行審計。

（2）虛擬網(wǎng)卡中發(fā)發(fā)現(xiàn)虛擬IP與訪問工作網(wǎng)站之間互相通信的流量，該流量為未經(jīng)加密的明文流量，該部分流量包含了客戶端發(fā)出流量以及工作網(wǎng)站返回流量，驗證客戶端流量會先經(jīng)過虛擬網(wǎng)卡進行流量處理，再經(jīng)由物理網(wǎng)卡進行實際網(wǎng)絡(luò)環(huán)境內(nèi)的流量傳輸；

（3）主機物理網(wǎng)卡中發(fā)現(xiàn)本機與VPN服務(wù)端之間的TCP以及OPENVPN協(xié)議流量，說明客戶端與服務(wù)端之間經(jīng)物理網(wǎng)卡傳輸?shù)牧髁恳呀?jīng)經(jīng)過了VPN服務(wù)處理轉(zhuǎn)變?yōu)榧用芰髁吭谡鎸嵕W(wǎng)絡(luò)環(huán)境內(nèi)進行傳輸；

經(jīng)過對于客戶端的流量抓取情況進行分析，可以得知在客戶端層面，訪問目標用戶網(wǎng)站的流量調(diào)用虛擬網(wǎng)卡進行傳輸，在此過程中虛擬網(wǎng)卡收到并要轉(zhuǎn)發(fā)出的流量為虛擬IP訪問真實訪問目標的流量，明確流量包的發(fā)送端和接受端后，VPN客戶端會對流經(jīng)虛擬網(wǎng)卡的流量進行加密再調(diào)用物理網(wǎng)卡進行實際網(wǎng)絡(luò)環(huán)境內(nèi)的流量傳輸。

VPN服務(wù)端

那對于服務(wù)端來說，服務(wù)端承擔的角色是接受客戶端的流量，將服務(wù)端作為請求發(fā)起方，向真實目標發(fā)送請求，由于服務(wù)端與訪問目標之間不存在加解密協(xié)商過程，服務(wù)端轉(zhuǎn)發(fā)流量應(yīng)為正常的http/https請求，因此在這個流量轉(zhuǎn)發(fā)的過程中一定涉及物理網(wǎng)卡接收客戶端流量的解密。

通過tcpdump工具分別抓取客戶端訪問目標時間段內(nèi)，服務(wù)端主機物理網(wǎng)卡以及TUN虛擬網(wǎng)卡的流量，利用wireshark對流量包進行審計：

[root@test ~]# tcpdump -i eth0 -s0 -w eth0.pcaptcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes16391 packets captured16394 packets received by filter0 packets dropped by kernel[root@test ~]# tcpdump -i tun0 -s0 -w tun0.pcaptcpdump: listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes16063 packets captured16066 packets received by filter0 packets dropped by kernel

（1）服務(wù)端物理網(wǎng)卡接受到了客戶端發(fā)送的加密傳輸流量；

（2）發(fā)現(xiàn)服務(wù)端虛擬網(wǎng)卡中存在虛擬IP與訪問工作網(wǎng)站之間互相通信的流量，該流量同樣為未經(jīng)加密的明文流量，證實在服務(wù)端虛擬網(wǎng)卡存在加密流量解密，將明文流量通過物理網(wǎng)卡傳輸至真實訪問目標；

（3）服務(wù)端物理網(wǎng)卡流量包抓取到服務(wù)端請求訪問真實訪問目標的明文傳輸流量，該流量經(jīng)過對比與客戶端wireshark抓取到的請求內(nèi)容一致，證明服務(wù)端確實將客戶端發(fā)送到請求進行代理轉(zhuǎn)發(fā)，且對于訪問目標來說，請求源為代理服務(wù)器的IP。

衍生問題

通過對客戶端和服務(wù)端的網(wǎng)絡(luò)流量包抓取分析可以看出，不論是客戶端還是服務(wù)端流經(jīng)虛擬網(wǎng)卡的請求流量，源IP均是10.8.0.6，但是實際環(huán)境中物理網(wǎng)卡并不能根據(jù)這個虛擬IP進行尋址，那么這里就會出現(xiàn)新的問題，服務(wù)端如何將請求返回包準確的返回給相應(yīng)的客戶端，虛擬網(wǎng)卡如何將虛擬網(wǎng)卡IP與真實客戶端主機進行關(guān)聯(lián)，并實現(xiàn)通知物理網(wǎng)卡完成準確的返回流量包分發(fā)？

OpenVPN服務(wù)端在虛擬網(wǎng)絡(luò)環(huán)境內(nèi)，本身承擔了“路由器”的角色，在tap模式下按照mac地址路由，tun模式則按照ip地址路由，在此次試驗環(huán)境中服務(wù)端配置為client-to-client，也就是tun模式，tun模式下路由項包含了客戶端和服務(wù)端之間建立連接時兩個TUN網(wǎng)卡之間的點對點路由，還包含了和VPN節(jié)點之外的目的網(wǎng)絡(luò)通信而設(shè)置的系統(tǒng)路由。通過兩項路由相結(jié)合的方式，告知對應(yīng)的虛擬IP所映射的真實物理IP信息，再經(jīng)過物理網(wǎng)卡實現(xiàn)真實網(wǎng)絡(luò)環(huán)境內(nèi)部的加密傳輸，因此本身TUN網(wǎng)卡技術(shù)不僅承擔了流量加密傳輸?shù)淖饔?，同時也是作為軟路由策略的關(guān)鍵承載，實現(xiàn)了通過軟件更靈活的組網(wǎng)形式。

VPN流量傳輸過程總結(jié)

通過上述抓包的解析，大家可能還不能夠直觀的了解客戶端的流量請求流程，圖片是最容易說明邏輯問題的形式，如下圖展示：

①用戶端連接VPN客戶端，客戶端依據(jù)配置文件創(chuàng)建一張?zhí)摂M網(wǎng)卡，客戶端所有進程的網(wǎng)絡(luò)連接首先明文傳輸至虛擬網(wǎng)卡

②經(jīng)過虛擬網(wǎng)卡的流量調(diào)用流量加密函數(shù)，對流量加密，傳輸至物理網(wǎng)卡

③物理網(wǎng)卡將經(jīng)過加密的流量在真實網(wǎng)絡(luò)環(huán)境內(nèi)發(fā)送到VPN服務(wù)端的物理網(wǎng)卡

④物理網(wǎng)卡將接收到的加密流量傳輸至虛擬網(wǎng)卡，虛擬網(wǎng)卡調(diào)用流量解密函數(shù)對流量進行解密

⑤虛擬網(wǎng)卡將經(jīng)過解密的明文流量進行代理轉(zhuǎn)換傳輸至物理網(wǎng)卡

⑥物理網(wǎng)卡將發(fā)向訪問目標的流量在真實網(wǎng)絡(luò)環(huán)境內(nèi)傳輸至真實訪問目標

不忘本心

那么回到最初的問題，我朋友上班摸魚的時候能不能夠被公司抓到？拋開現(xiàn)實不同廠商VPN功能豐富程度不談，在此次測試過程中朋友的摸魚行為還是可以被審計到的，雖然在網(wǎng)絡(luò)傳輸層OpenVPN將客戶端與服務(wù)端端流量進行了加密，避免了中間人監(jiān)聽網(wǎng)絡(luò)流量導致的信息失竊事件，但是無論是在客戶端還是服務(wù)端，通過流量監(jiān)聽工具均可以監(jiān)聽到虛擬網(wǎng)卡中傳輸?shù)拿魑牧髁?，而在同一時間內(nèi)服務(wù)端分配給客戶端的虛擬IP為唯一的，通過虛擬IP的身份比對就可以抓到最終的摸魚達人，當初摸魚笑的有多大聲，被發(fā)現(xiàn)處罰時就有多狼狽。

天馬行空

本人主要參與網(wǎng)絡(luò)安全運營工作，其中就涉及蜜網(wǎng)建設(shè)，測試完相關(guān)的技術(shù)就有了一些天馬行空的想法——在網(wǎng)絡(luò)安全攻防演練的過程中VPN可能是紅隊成員眼前一亮的線索，往年通過VPN直接攻破邊界防護，如入無人之境的案例也皆有發(fā)生。

想象一下，假如說在信息搜集的過程中看到了靶標的VPN連接配置信息，那好像就是狼看到了羊，羊看到了草，那根本不可能忍住，好不好？

那換個角度想想，根據(jù)上述的測試，把真實的OpenVPN服務(wù)端換成帶有流量監(jiān)聽的隔離蜜罐，當你嘗試連接還連接成功，以為一舉拿下興高采烈準備寫報告的時候，你的操作都被防守方看在眼里，想法全部暴露的時候，就好像在歌手決賽舞臺上唱豬豬俠一樣，一瞬間才發(fā)現(xiàn)小丑竟是我自己？！

心態(tài)比較好覺得被防守方抓到IP信息也沒啥，反正是個人熱點，掛了梯子，他們也猜不到我是誰，躲在電腦屏幕之后沒有人知道是自己，自己不尷尬尷尬的就是別人。不過這還不是最恐怖的，最恐怖的是當你通過配置文件連接成功的時候，電腦或者自己的“肉只因”自己上線被溯源了？！當初到嘴的肥羊扭頭發(fā)現(xiàn)是個披著羊皮的老虎，就問你刺激不刺激，具體的OpenVPN配置文件反制原理請閱讀下面的文章，這里就不再贅述

https://www.freebuf.com/news/175862.html

題外話

網(wǎng)絡(luò)安全最緊張刺激的環(huán)節(jié)就是攻防，在攻防的過程中不僅是技術(shù)能力的展現(xiàn)，也是內(nèi)心深處的博弈，當你覺得你拿到了大門的鑰匙，也有可能你步入了迷惑你的陷阱，行差踏錯也就是一念間，黑客和白帽也只是一念之間，同一種技術(shù)黑客眼中是竊密，白帽眼中是御敵，而作為安全從業(yè)人員，更應(yīng)該做的是守住內(nèi)心一方清明，技術(shù)本身沒有黑白是非，但是作為安全從業(yè)者應(yīng)該有著自己的底線。