上網限制和×××基本原理

目前在國內基本訪問不了谷歌站點和機器人的站點,下載個gradle這個都要等很久。所以如果不×××很多工作都沒辦法正常做。所以在學習×××的同時也順便了解了下目前限制網絡訪問的一些基本知識。


網絡限制和監控應該說大家都有體會。比如很多公司都會限制一些網站的訪問,比如網盤,視屏網站。有時也會對你訪問的內容進行監控。還有一些公共WIFI,可能限制你只能訪問80端口。在比如在國內無法訪問谷歌,Facebook,機器人等網站。要想繞過這些限制,必須先知道他們是如何限制的。


本文主要是從技術角度來了解的網絡限制方式和應對方式。並不做任何翻譯方式的推薦和指導。對於網絡的知識,還是停留在上過網絡課的水平,文章內容也都是自己瞭解後總結的。




DNS污染和劫持

以下解釋來之百度百科:

某些網絡運營商爲了某些目的,對DNS進行了某些操作,導致使用ISP的正常上網設置無法通過域名取得正確的IP地址。
某些國家或地區出於某些目的爲了防止某網站被訪問,而且其又掌握部分國際DNS根目錄服務器或鏡像,也會利用此方法進行屏蔽。


目前我們訪問網站主要都是通過域名進行訪問,而真正訪問這個網站前需要通過DNS服務器把域名解析爲IP地址。而普通的DNS服務使用UDP協議,沒有任何的認證機制.DNS劫持是指返回給你一個僞造頁面的IP地址,DNS污染是返回給你一個不存在的頁面的IP地址。


比如你使用電信,聯通,移動的寬帶,默認你是不需要設置任何DNS服務器的。這些DNS服務器由他們提供。一旦檢測到你訪問的網頁是不允許的訪問的,就會返回一個不存在的網頁。而很多運營商也會使用DNS劫持來投放一些廣告。


 

解決辦法:


1.使用OpenDNS(208.67.222.222)或GoogleDNS(8.8.8.8)(現在不太好用,被封鎖,速度慢)

2.使用一些第三方的DNS服務器

3.自己用VPS搭建DNS服務器

4.修改機器的主機文件,直接IP訪問


封鎖IP

通過上面一些方式,可以繞過DNS污染,通過IP地址訪問無法訪問的網頁。但是目前針對IP進行大範圍的封鎖。雖然谷歌這種大公司有很多鏡像IP地址,但是目前基本全部被封鎖掉,有漏網的可能也堅持不了多久。而且很多小公司的服務是部署在一些第三方的主機上,所以封鎖IP有時會誤傷,封鎖一個IP導致主機上本來可以使用的頁面也無法訪問了。


不過目前不可能把所有國外的IP全部封鎖掉,所以我們採用機會從國內連接到國外的VPS,進行×××。


解決辦法:


1.使用VPS搭建代理

2.使用IPV6(IPV6地址巨大,採用封地址不現實,但是目前國內只有部分高校部署了IPV6)

 


封鎖HTTP代理

對於沒有辦法搭建VPS的人來說,最好的辦法就是使用HTTP代理。客戶端不在直接請求目標服務器,而是請求代理服務器,代理服務器在去請求目標服務器。然後返回結果。關於HTTP代理可以參考

“HTTP權威指南”第六章:代理

117096-20160506050828872-1129779106.png

對於HTTP代理來說,封鎖起來非常簡單。因爲HTTP協議是明文,請求消息中就帶有要請求的URL或IP地址,這樣很容易就被檢測到。對於HTTPS來說,雖然通信是進行加密了,但是在建連之前會給代理服務器發送CONNECT方法,這裏也會帶上要訪問的遠端服務器地址。如果代理服務器在國外,在出去前就會被檢測到。如果代理服務器在國內,呵呵,你也出不去啊。



對於HTTP代理,因爲是明文,所以很容易被服務器瞭解你的一些數據。所以不要隨便使用第三方的HTTP代理訪問HTTP網站,而HTTPS雖然不知道你的數據,但是可以知道你去了那裏。


解決辦法:


1.使用VPS搭建***

2.使用第三方***


封鎖***

虛擬專用網英語:虛擬專用網,簡稱***),是一種常用於連接中,大型企業或團體與團體間的私人網絡的通訊方法虛擬私人網絡的訊息透過公用的網絡架構(例如:互聯網)來傳送內聯網的網絡訊息。它利用已加密的通道協議(Tunneling Protocol)來達到保密,發送端認證,消息準確性等私人消息安全效果。


正常網絡通信時,所有網絡請求都是通過我們的物理網卡直接發送出去。而***是客戶端使用相應的***協議先與***服務器進行通信,成功連接後就在操作系統內建立一個虛擬網卡,一般來說默認PC上所有網絡通信都從這虛擬網卡上進出,經過***服務器中轉之後再到達目的地。

how-***-protects-your-data.png

通常***協議都會對數據流進行強加密處理,從而使得第三方無法知道數據內容,這樣就實現了×××。×××時***服務器知道你乾的所有事情(HTTP,對於HTTPS,它知道你去了哪)。


***有多種協議:OPEN***、PPTP、L2TP/IPSec、SSL***、IKEv2 ***,Cisco ***等。其中的PPTP和L2TP是明文傳輸協議。只負責傳輸,不負責加密。分別利用了MPPE和IPSec進行加密。


D55)U3T)X$2HE$TBQXI1I5X.png

[S@RAQT~X8{AA6R6QSZD8_O.png


對於***和其他一些加密的傳輸的協議來說,沒有辦法直接獲取明文的請求信息,所以沒有辦法直接封鎖,而是使用了監控的方式:

暴力破解:

對於一些使用弱加密方式的協議來說,直接使用暴力破解檢查傳輸內容。比如PPTP使用MPPE加密,但是MPPE是基於RC4,對於強大的防火牆背後的超級計算機集羣,破解就是幾秒鐘的事情。

破解後明文中一旦包含了違禁內容,請求就會被封。而對應的IP可能會進入重點關懷列表。

特徵檢測:

要想成功×××都必須與對應的遠程服務器建立連接,然後再用對應的協議進行數據處理並傳輸
而問題就出在這裏:×××工具和遠程服務器建立連接時,如果表現的很獨特,在一大堆流量裏很顯眼,就會輕易被GFW識別出從而直接阻斷連接,而***(尤其是OPEN***)和SSH這方面的問題尤其嚴重。

流量監控:

當一個***地址被大量人請求,並保持長時間連接時,就很容易引起關注的.ssh接口有大量數據請求。一般會結合其他特徵。

深度包檢測:

深度數據包檢測英語:深度數據包檢測,縮寫爲DPI),又稱完全數據包探測(完整的數據包檢查)或信息萃取塔(信息提取,IX),一種的英文電腦網絡數據包過濾技術,用來檢查通過檢測點之數據包數據部分(亦可能所有遊戲其標頭),以搜索不匹配規範之協議,病毒垃圾郵件,***,或以預定之準則來決定數據包是否可通過或需被路由至其他不同目的地,亦或是爲了收集統計數據之目的。

比如我們用HTTPS來訪問一個網站,TLS / SSL協議在建連過程如下:

sy10660a.gif

很明顯的會發送“client hello”和“server hello”這種特診很明顯的信息。(當然不會根據這個就封掉,否則https沒法用了)。而後續會有服務端證書發送,驗證,客戶端密鑰協商等過程。有明顯的協議特徵。

screenshot-domain-date-time.png

下面是網上找的兩張圖:提醒大家最好不要隨便用不安全的***來訪問不合適的網頁,開開的Android沒啥問題。

screenshot-domain-date-time-1.png

Socks代理/SSH Socks

SOCKS是一種網絡傳輸協議,主要用於客戶端與外網服務器之間通訊的中間傳遞。SOCKS是”SOCKetS”的縮寫[1]

防火牆後的客戶端要訪問外部的服務器時,就跟SOCKS代理服務器連接。這個代理服務器控制客戶端訪問外網的資格,允許的話,就將客戶端的請求發往外部的服務器。

這個協議最初由David Koblas開發,而後由NEC的Ying-Da Lee將其擴展到版本4。最新協議是版本5,與前一版本相比,增加支持UDP、驗證,以及IPv6

根據OSI模型,SOCKS是會話層的協議,位於表示層傳輸層之間

與HTTP代理的對比

SOCKS工作在比HTTP代理更低的層次:SOCKS使用握手協議來通知代理軟件其客戶端試圖進行的連接SOCKS,然後儘可能透明地進行操作,而常規代理可能會解釋和重寫報頭(例如,使用另一種底層協議,例如FTP;然而,HTTP代理只是將HTTP請求轉發到所需的HTTP服務器)。雖然HTTP代理有不同的使用模式,CONNECT方法允許轉發TCP連接;然而,SOCKS代理還可以轉發UDP流量和反向代理,而HTTP代理不能。HTTP代理通常更瞭解HTTP協議,執行更高層次的過濾(雖然通常只用於GET和POST方法,而不用於CONNECT方法)

Socks代理本身協議是明文傳輸,雖然相對HTTP有一些優勢,但是明文也導致Socks代理很容易被封。所以可以考慮對Socks進行加密。所以出現了SSH Socks,對於MAC和Linux來說,不需要Client就可以進行訪問。詳細可以看:SSH隧道技術簡介:端口轉發&SOCKS代理

但是網上看有些地區好像會對一些VPS的SSH進行端口乾擾。我在武漢好像SSH到我的VPS一會就會斷。在上海一直沒這問題。而且SSH一般是小流量數據,如果數據量特別大,也會被認爲是×××,進入特別關懷列表。

 

Shadowsocks

 

認準官網:https://shadowsocks.org/en/index.html (.com那個是賣賬號的)

A secure socks5 proxy,

designed to protect your Internet traffic.

Shadowsocks 目前不容易被封殺主要是因爲:

  1. 建立在socks5協議之上,socks5是運用很廣泛的協議,所以沒辦法直接封殺socks5協議

  2. 使用socks5協議建立連接,而沒有使用***中的服務端身份驗證和密鑰協商過程。而是在服務端和客戶端直接寫死密鑰和加密算法。所以防火牆很難找到明顯的特徵,因爲這就是個普通的socks5協議。

  3. Shadowsock搭建也比較簡單,所以很多人自己架設VPS搭建,個人使用流量也很小,沒法通過流量監控方式封殺。

  4. 自定義加密方式和密鑰。因爲加密主要主要是防止被檢測,所以要選擇安全係數高的加密方式。之前RC4會很容易被破解,而導致被封殺。所以現在推薦使用AES加密。而在客戶端和服務端自定義密鑰,泄露的風險相對較小。

所以如果是自己搭建的Shadosocks被封的概率很小,但是如果是第三方的Shadeowsocks,密碼是server定的,你的數據很可能遭受到中間人***。

 

順便說一下,Shadowssocks是天朝的clowwindy大神寫的。不過Shadowsocks項目源碼已經從github上刪除了並停止維護了,但是release中還有源碼可以下載。https://github.com/shadowsocks/shadowsocks

 

Shadowsocks-rss

前面認爲Shadowssocks特徵並不是很明細,但是瞭解協議工作原理後會發現,SS協議本身還有有漏洞,可以被利用來檢測特徵,具體討論看:ShadowSocks協議的弱點分析和改進。 裏面中間那些撕逼就不用看了,我總結了下大致意思是:

協議過於簡單,並且格式固定,很容易被髮起中間人***。先看看協議結構


+--------------+---------------------+------------------+----------+
| Address Type | Destination Address | Destination Port |   Data   |
+--------------+---------------------+------------------+----------+
|      1       |       Variable      |         2        | Variable |
+--------------+---------------------+------------------+----------+

地址類型的可能值是1(IPv4),4(IPv6),3(主機名)。對於IPv4地址,它被打包成一個32位(4字節)的大端整數。對於IPv6地址,使用緊湊表示(16字節數組)。對於主機名,目的地址的第一個字節表示長度,這將主機名的長度限制爲255.目標端口也是一個大端的整數。

該請求使用具有隨機IV和預共享密鑰的指定密碼進行加密,然後變成所謂的有效載荷

結構很簡單,上面解釋也很清楚.Client每一個請求都是這種格式,然後進行加密.Server端解密然後解析。看起來沒什麼問題,沒有密鑰你無法模擬中間人***,也沒什麼明顯特徵。但是看看服務器處理邏輯會發現存在一些問題:

客戶數據在加密目前用的最多的是AES系列,加密後在協議數據前會有16位的IV而服務器段解析後,首先判斷請求是否有效,而這個判斷很簡單:

判斷的依據就是Address Type的那個字節,看它是不是在那個三個可能取值,如果不是,立即斷開連接,如果是,就嘗試解析後面的地址和端口進行連接。

如果能發起中間人***,模擬客戶請求,這個就是一個很明顯的特徵,如果把地址類型窮舉各種情況,其中只有3種情況會連接成功。那麼很可能就是一個Shadowsocks服務器。

所以只需要先劫持一條socks5的請求,因爲AES加密後地址類型位置是固定的(第17位),篡改這一位,窮舉256種情況(AES-256),然後發送給服務器。如果服務器在3種情況沒有關閉連接,就說明這個很可能是Shadowsock服務。你這個IP很快就進入關懷列表了。

。這裏的關鍵就是AES加密明文和密文對應關係密碼學不是太懂,貼帖子裏面一個回覆:

舉個例子,現在有一個協議包,共7個字節

0x01, 0x08, 0x08, 0x08, 0x08, 0x00, 0x50

對照SOCKS5協議,很明顯這是一個IPv4的包(第一個字節是0x01),的英文目的地8.8.8.880端口

被2.6.8加密了以後(密碼abc,加密方式aes-256-cfb),數據包就變成了這樣

0xbb, 0x59, 0x1c, 0x4a, 0xb9, 0x0a, 0x91, 0xdc, 0x07, 0xef, 0x72, 0x05, 0x90, 0x42, 0xca, 0x0d, 0x4c, 0x3b, 0x87, 0x8e, 0xca, 0xab, 0x32

前16個字節,從0xbb0x0d,都是iv,根據問題中提到的弱點和之前的總結,只需要修改0x4c,即真正密文中的第一個字節,就可要起到修改明文中的第一個字節的效果。

把那就0x4c修改分類中翻譯0x4d吧,解密以後的結果是

0x00, 0x08, 0x08, 0x08, 0x08, 0x00, 0x50

的確只有第一個字節被改掉了,根據breakwa11的理論,不難推出其他情況,其中合法的是

0x4e => 0x03 (Domain Name)0x49 => 0x04 (IPv6)

所以目前Shadowsocks應該是比較容易被檢測出來。但是爲什麼沒有被封掉,呵呵,就不知道了。所以這個項目目的就是在SS基礎上進行一些混淆。因爲原有實現確實有漏洞。不過目前這個項目好像也停止更新了。並且木有開源。

當然如果是自己用完全可以自己修改一個私有協議,這樣就沒法被檢測到了。但是需要同時修改服務器段,MAC客戶端,Windows客戶端,Android客戶端。

GoAgent和GoProxy

Google App Engine是一個開發,託管網絡應用程序的平臺,使用Google管理的數據中心

sy10660a.gif


GoAgent的運行原理與其他代理工具基本相同,使用特定的中轉服務器完成數據傳輸。它使用Google App Engine的服務器作爲中傳,將數據包後發送至Google服務器,再由Google服務器轉發至目的服務器,接收數據時方法也類似[3] 。由於服務器端軟件基本相同,該中轉服務器既可以是用戶自行架設的服務器,也可以是由其他人架設的開放服務器。

GoAgent其實也是利用GAE作爲代理,但是因爲他是連接到google的服務器,因爲在國內現在google大量被封,所以GoAgent也基本很難使用。目前github上源碼也已經刪除。

但是GoAgent本身不依賴於GAE,而且使用Python編寫,完全可以部署到VPS上進行代理。GoProxy是GoAgent的後續項目https://github.com/phuslu/goproxy,還有一個XX-NET:https://github.com/XX-net/XX-Net 有興趣都可以去了解下。

Tor

TorThe Onion Router洋蔥路由器)是實現匿名通信的自由軟件。Tor是第二代洋蔥路由的一種實現,用戶通過Tor可以在因特網上進行匿名交流。


The Tor network is a group of volunteer-operated servers that allows people to improve their privacy and security on the Internet. Tor’s users employ this network by connecting through a series of virtual tunnels rather than making a direct connection, thus allowing both organizations and individuals to share information over public networks without compromising their privacy. Along the same line, Tor is an effective censorship circumvention tool, allowing its users to reach otherwise blocked destinations or content. Tor can also be used as a building block for software developers to create new communication tools with built-in privacy features.

下面的圖來自官網的介紹。具體內容大家可以自己看,簡單說和其他×××方式不同,簡單可以理解爲Tor有一羣代理服務器,然後要訪問遠端站點,是通過隨機的代理路徑來完成的,數據經歷了多個代理服務器的傳遞。它主要作用是隱藏訪問者信息,而×××只是順帶的功能。

要訪問遠程站點,Client需要知道Tor nodes,這些nodes就是普通加入的用戶,就好像P2P下載一樣。獲取nodes信息後,會隨機選擇一條路徑訪問。 因爲這個原因,Tor的速度可能不會很好。

htw1.png 

htw2.png

htw3.png

而關於Tor的漏洞和檢測看這裏:Tor真的十分安全麼 其原理以及漏洞詳解!

目前有結合Tor+Shadowsocks前置代理使用的。

 

Reference:

***×××,不安全的加密,不要相信牆內公司

GFW的工作原理(1) ————GFW是如何識別並封鎖×××工具的

關於×××和匿名與網絡安全類科普文大集合

爲什麼不應該用 SSL ×××

科學上網的一些原理


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章