Telegram Web Link
莫名想統計下今天帶機場們節點狀態怎樣(機場主投就可以了)(有幾種狀態就選幾種)
Final Results
24%
vmess 被牆
4%
vless 被牆
5%
trojan 被牆
30%
ss/ssr 被牆
52%
沒事
某些機場給反向牆了一次就趕緊換轉發方式吧
別牆了一次又一次還死磕老方案
早說不建議 ws 更不建議 ws over ws 了怎麼還死不悔改
一拉一拉多的建議考慮聚合一下
對於 TLS 方案該排查證書特徵與主動探測的可能性
但凡有點腦子都不至於這麼多次每次都被反向吧
本次自簽名不帶雙端驗證的 TLS+HTTP/Socks5 長時間大流量都活著的,可以說是沒有做特別嚴格的主動探測了,更不存在 MITM
關於 DNS 汙染,我個人的建議是:

機場面板或訂閱站等基礎設施含自建 DoH (可以考慮帶用戶驗證)
下發訂閱中帶 DoH 以供解析節點地址(已知 Clash 與 Shadowrocket 均有支援,但實測 CFA 中 default-nameserver 可用 DoH 但 CFW 只允許純 IP 。 Shadowrocket 由於未找到完整文檔而暫且沒有測試)

或:

機場面板定時解析快取 IP ,直接下發
本次, DNS 汙染與反向牆並沒有直接關聯
關於機場面板域名的問題,在強制 HTTPS 的前提下提供幾項淺顯的對抗自動化探測的思路:
一是針對訂閱及 API 。可以考慮反向代理到別的路徑。或使明顯試探性的請求回報 404 而非如 JSON 裡包個明確的 Error 。
二是針對前端(尤其是首頁)。除完全訂製前端外,成本更低的方案如:盡量簡化以便修改無須登入即可查看的區域(含其利用到的資源),或是放置人機驗證。(短期的通用方案還有多用 JS 加載並混淆,以及五秒盾等,但理論上主動探測並非不可以用 Webview 先允許後判定)(考慮棄用部分 JS 轉而編譯並混淆 wasm 也有助於緩解)
未來的 ECH 也有助於解決此項問題,只是週期太久。
至於如果中國的閉源瀏覽器參與探測和上報,那確實是很可能沒有辦法的。

目前網頁探測相關的肯定沒有發展得那麼快,先把基於路徑的做好就可以了。
對於機場,幾個似乎靈驗的結論:(均假定用戶都有查詢 DNS 記錄且跑上服務)
未備案域名綁定中國大陸中轉 -> 域名汙染 & 管局通報
未備案域名綁定國際直連 -> 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 有顯著的統計學差異。
我個人確沒有瞭解針對超大流量規模的基於機器學習或其他啟發式方法的防火牆架構設計,甚至沒有讀到過比較現實的基於流統計的防火牆架構。但我主觀認為這些在特定的總體架構下是可行的。
總之,加油。
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://github.com/v2fly/v2fly-github-io/commit/1dfb8ce883f1d48ecfa545ff43ef283c239dad97
才看到 VLESS 壽終正寢。很顯然的教訓:我們需要的是靈活的 transport 而非多樣的 Socks-like protocol。這也是 Hysteria 和 naïveproxy 總是令人失去興趣的原因。
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官方源可能出现问题,建议暂停安装
關於這個識別網站特徵,我的觀點是,這是一個事實,不是發現。事實上在特殊時期識別 SSPanel 並封鎖域名(行為:DNS 不汙染,SNI/Host RST)已經是成為常態了,因此上圖除了 3 外,我均贊同。
對於原文說法,我給出的簡易解決方案是開盾。當然盾可以有很多種,可以用 ngx_waf 也可以用各種 CDN 的,未必像 CloudFlare 那樣比較影響使用。但是開盾就不能訂閱了,訂閱連結報 token is errortoken is null 其實是更麻煩的特徵。推而廣之還有別的 API 比如 Telegram Bot,Node,Payment 等。因此我的實際建議是去實現可變的 api path 並對除 api path 外的地址自訂一個盾。
其實還有更現代的解決方案,就是 DoH+ECH 但此方案如今確實難以大面積使用。
2025/06/27 03:18:07
Back to Top
HTML Embed Code: