莫名想統計下今天帶機場們節點狀態怎樣(機場主投就可以了)(有幾種狀態就選幾種)
Final Results
24%
vmess 被牆
4%
vless 被牆
5%
trojan 被牆
30%
ss/ssr 被牆
52%
沒事
機場被牆統計(機場主 & 用戶均可投票)
Final Results
8%
VMessAEAD (AlterID=0)
10%
VMess
4%
ShadowsocksAEAD
5%
Shadowsocks
4%
Trojan
6%
ShadowsocksR
68%
無
某些機場給反向牆了一次就趕緊換轉發方式吧
別牆了一次又一次還死磕老方案
早說不建議 ws 更不建議 ws over ws 了怎麼還死不悔改
一拉一拉多的建議考慮聚合一下
對於 TLS 方案該排查證書特徵與主動探測的可能性
但凡有點腦子都不至於這麼多次每次都被反向吧
別牆了一次又一次還死磕老方案
早說不建議 ws 更不建議 ws over ws 了怎麼還死不悔改
一拉一拉多的建議考慮聚合一下
對於 TLS 方案該排查證書特徵與主動探測的可能性
但凡有點腦子都不至於這麼多次每次都被反向吧
關於 DNS 汙染,我個人的建議是:
機場面板或訂閱站等基礎設施含自建 DoH (可以考慮帶用戶驗證)
下發訂閱中帶 DoH 以供解析節點地址(已知 Clash 與 Shadowrocket 均有支援,但實測 CFA 中 default-nameserver 可用 DoH 但 CFW 只允許純 IP 。 Shadowrocket 由於未找到完整文檔而暫且沒有測試)
或:
機場面板定時解析快取 IP ,直接下發
機場面板或訂閱站等基礎設施含自建 DoH (可以考慮帶用戶驗證)
下發訂閱中帶 DoH 以供解析節點地址(已知 Clash 與 Shadowrocket 均有支援,但實測 CFA 中 default-nameserver 可用 DoH 但 CFW 只允許純 IP 。 Shadowrocket 由於未找到完整文檔而暫且沒有測試)
或:
機場面板定時解析快取 IP ,直接下發
關於機場面板域名的問題,在強制 HTTPS 的前提下提供幾項淺顯的對抗自動化探測的思路:
一是針對訂閱及 API 。可以考慮反向代理到別的路徑。或使明顯試探性的請求回報 404 而非如 JSON 裡包個明確的 Error 。
二是針對前端(尤其是首頁)。除完全訂製前端外,成本更低的方案如:盡量簡化以便修改無須登入即可查看的區域(含其利用到的資源),或是放置人機驗證。(短期的通用方案還有多用 JS 加載並混淆,以及五秒盾等,但理論上主動探測並非不可以用 Webview 先允許後判定)(考慮棄用部分 JS 轉而編譯並混淆 wasm 也有助於緩解)
未來的 ECH 也有助於解決此項問題,只是週期太久。
至於如果中國的閉源瀏覽器參與探測和上報,那確實是很可能沒有辦法的。
目前網頁探測相關的肯定沒有發展得那麼快,先把基於路徑的做好就可以了。
一是針對訂閱及 API 。可以考慮反向代理到別的路徑。或使明顯試探性的請求回報 404 而非如 JSON 裡包個明確的 Error 。
二是針對前端(尤其是首頁)。除完全訂製前端外,成本更低的方案如:盡量簡化以便修改無須登入即可查看的區域(含其利用到的資源),或是放置人機驗證。(短期的通用方案還有多用 JS 加載並混淆,以及五秒盾等,但理論上主動探測並非不可以用 Webview 先允許後判定)(考慮棄用部分 JS 轉而編譯並混淆 wasm 也有助於緩解)
未來的 ECH 也有助於解決此項問題,只是週期太久。
至於如果中國的閉源瀏覽器參與探測和上報,那確實是很可能沒有辦法的。
目前網頁探測相關的肯定沒有發展得那麼快,先把基於路徑的做好就可以了。
https://github.com/v2fly/v2ray-core/issues/1823
有理由相信 GFW 已開始基於 Xray-core 默認配置的伺服器端 TLS 指紋封鎖了部分 IPv4 。
* Xray-core 與 v2ray-core 的 TLS 指紋似乎還有所不同
有理由相信 GFW 已開始基於 Xray-core 默認配置的伺服器端 TLS 指紋封鎖了部分 IPv4 。
* Xray-core 與 v2ray-core 的 TLS 指紋似乎還有所不同
GitHub
服务端 TLS 指纹 · Issue #1823 · v2fly/v2ray-core
TL;DR v2ray TLS 服务器 存在独特的指纹。 解决方案:请考虑应用前置(套个 Nginx HAProxy Caddy 什么的) 抱歉,有点像“弄个大新闻”,实际影响多大还需项目组人士评估。 起因 最近网络上流传一份 IP 列表,很多是 v2ray TLS,也有部分误报。 TLS 协议实现复杂,参数多, 考虑到 v2ray 之前在 客户端 方面出现了独特的指纹,服务器出现这种问题也...
對於機場,幾個似乎靈驗的結論:(均假定用戶都有查詢 DNS 記錄且跑上服務)
未備案域名綁定中國大陸中轉 -> 域名汙染 & 管局通報
未備案域名綁定國際直連 -> IP 牆
用備案域名固然是一種方案
但也並非沒有別的方案
未備案域名綁定中國大陸中轉 -> 域名汙染 & 管局通報
未備案域名綁定國際直連 -> IP 牆
用備案域名固然是一種方案
但也並非沒有別的方案
https://github.com/net4people/bbs/issues/129
我個人仍堅持認為 Client TLS fingerprints 是導致封鎖的主因,Server TLS fingerprints、Let's Encrypt、單 Client 並行數、流量特徵、域名行為、IP 段敏感度等亦可能與之各自權重決定屏蔽行為。
「TLS over TLS」確實不能說沒有特徵,但絕非強特徵。TLS handshake 的 len 確實可能與常規的 HTTP/1.1 及 HTTP/2 有顯著的統計學差異。
我個人確沒有瞭解針對超大流量規模的基於機器學習或其他啟發式方法的防火牆架構設計,甚至沒有讀到過比較現實的基於流統計的防火牆架構。但我主觀認為這些在特定的總體架構下是可行的。
總之,加油。
我個人仍堅持認為 Client TLS fingerprints 是導致封鎖的主因,Server TLS fingerprints、Let's Encrypt、單 Client 並行數、流量特徵、域名行為、IP 段敏感度等亦可能與之各自權重決定屏蔽行為。
「TLS over TLS」確實不能說沒有特徵,但絕非強特徵。TLS handshake 的 len 確實可能與常規的 HTTP/1.1 及 HTTP/2 有顯著的統計學差異。
我個人確沒有瞭解針對超大流量規模的基於機器學習或其他啟發式方法的防火牆架構設計,甚至沒有讀到過比較現實的基於流統計的防火牆架構。但我主觀認為這些在特定的總體架構下是可行的。
總之,加油。
GitHub
Large scale blocking of TLS-based censorship circumvention tools in China · Issue #129 · net4people/bbs
Starting from October 3, 2022 (Beijing Time), more than 100 users reported that at least one of their TLS-based censorship circumvention servers had been blocked. The TLS-based circumvention protoc...
https://github.com/Dreamacro/clash/blob/master/transport/trojan/trojan.go#L27
https://www.v2fly.org/config/transport.html#tlsobject
個人傾向於把各通用 Client 的 TLS ALPN 換成符合並行特徵的東西。比如說,Trojan 動輒幾十連接數,怎麼看都不 h2 吧。
(我是真沒公開講過這個東西嗎?老早就在小群說了,今天翻頻道居然沒看到)
https://www.v2fly.org/config/transport.html#tlsobject
個人傾向於把各通用 Client 的 TLS ALPN 換成符合並行特徵的東西。比如說,Trojan 動輒幾十連接數,怎麼看都不 h2 吧。
(我是真沒公開講過這個東西嗎?老早就在小群說了,今天翻頻道居然沒看到)
GitHub
clash/transport/trojan/trojan.go at master · Dreamacro/clash
A rule-based tunnel in Go. Contribute to Dreamacro/clash development by creating an account on GitHub.
https://github.com/v2fly/v2fly-github-io/commit/1dfb8ce883f1d48ecfa545ff43ef283c239dad97
才看到 VLESS 壽終正寢。很顯然的教訓:我們需要的是靈活的 transport 而非多樣的 Socks-like protocol。這也是 Hysteria 和 naïveproxy 總是令人失去興趣的原因。
才看到 VLESS 壽終正寢。很顯然的教訓:我們需要的是靈活的 transport 而非多樣的 Socks-like protocol。這也是 Hysteria 和 naïveproxy 總是令人失去興趣的原因。
GitHub
v5: add VLESS deprecated warning · v2fly/v2fly-github-io@1dfb8ce
V2Fly Website & Documentation. Contribute to v2fly/v2fly-github-io development by creating an account on GitHub.
Forwarded from LoopDNS资讯播报
速报:宝塔面板疑似出现全新高危漏洞,目前已出现大面积入侵
影响版本:7.9.6及以下且使用nginx用户
风险等级:极高
处置建议: 停止使用BT面板且更换阿帕奇 [宝塔官方建议暂停面板]
排查方式: /www / server/ nginx/ sbin 目录下文件
1. nginx 11.80 MB
2. nginxBak 4.55 MB[备份]
3. nginx 4.51M [木马]
特征:
1.大小4.51
2.时间近期
3.nginx&nginxBAK双文件
入侵者通过该漏洞拥有root权限,受限于面板高权限运行,修改宝塔各种账号密码+SSH账号密码均为无效。
入侵者可以修改nginx配置文件+数据库文件+网站根目录文件
站点可能出现大量日志同时CPU异常占用,暂不清楚漏洞点,切勿随意点击清除日志按钮
注: 大量新装用户反馈出现挂马,目前BT官方源可能出现问题,建议暂停安装
影响版本:7.9.6及以下且使用nginx用户
风险等级:极高
处置建议: 停止使用BT面板且更换阿帕奇 [宝塔官方建议暂停面板]
排查方式: /www / server/ nginx/ sbin 目录下文件
1. nginx 11.80 MB
2. nginxBak 4.55 MB[备份]
3. nginx 4.51M [木马]
特征:
1.大小4.51
2.时间近期
3.nginx&nginxBAK双文件
入侵者通过该漏洞拥有root权限,受限于面板高权限运行,修改宝塔各种账号密码+SSH账号密码均为无效。
入侵者可以修改nginx配置文件+数据库文件+网站根目录文件
站点可能出现大量日志同时CPU异常占用,暂不清楚漏洞点,切勿随意点击清除日志按钮
注: 大量新装用户反馈出现挂马,目前BT官方源可能出现问题,建议暂停安装
https://github.com/v2board/v2board/commit/adf465696af9f0de9d5cb015d1a28915c5cfb22e#diff-8577d9c21ea7c547d75c5eb33a466dff6090d317dbb952004d6b6ff96fccfd49
不多說。這次 V2board 漏洞並非弱口令所致。1.6.0 及之前的版本不受影響。
不多說。這次 V2board 漏洞並非弱口令所致。1.6.0 及之前的版本不受影響。
GitHub
update: new auth · v2board/v2board@adf4656
🚀A multiple proxy protocol manage panel application interface - update: new auth · v2board/v2board@adf4656
關於這個識別網站特徵,我的觀點是,這是一個事實,不是發現。事實上在特殊時期識別 SSPanel 並封鎖域名(行為:DNS 不汙染,SNI/Host RST)已經是成為常態了,因此上圖除了 3 外,我均贊同。
對於原文說法,我給出的簡易解決方案是開盾。當然盾可以有很多種,可以用 ngx_waf 也可以用各種 CDN 的,未必像 CloudFlare 那樣比較影響使用。但是開盾就不能訂閱了,訂閱連結報 token is error 或 token is null 其實是更麻煩的特徵。推而廣之還有別的 API 比如 Telegram Bot,Node,Payment 等。因此我的實際建議是去實現可變的 api path 並對除 api path 外的地址自訂一個盾。
其實還有更現代的解決方案,就是 DoH+ECH 但此方案如今確實難以大面積使用。
對於原文說法,我給出的簡易解決方案是開盾。當然盾可以有很多種,可以用 ngx_waf 也可以用各種 CDN 的,未必像 CloudFlare 那樣比較影響使用。但是開盾就不能訂閱了,訂閱連結報 token is error 或 token is null 其實是更麻煩的特徵。推而廣之還有別的 API 比如 Telegram Bot,Node,Payment 等。因此我的實際建議是去實現可變的 api path 並對除 api path 外的地址自訂一個盾。
其實還有更現代的解決方案,就是 DoH+ECH 但此方案如今確實難以大面積使用。