Pages

Wednesday, 31 March 2021

程晓农:《美国印太战略框架》解析

 1月13日澳大利亚战略政策研究所的《战略家(Strategist》网站立即刊登了一篇文章“Declassification of secret document reveals US strategy in the Indo-Pacific”,介绍美国解密“最敏感的国家安全文件之一”(即《美国印太战略框架》)的意涵。

近年来介入中印太地区颇深的中国也高度关注这个文件,北京的《多维新闻》1月14日刊文报道了此事。

更值得注意的是,中国最近在印尼沿海为战略核潜艇作战进行大规模水文侦测,这反映出中国为打通战略核潜艇的水下南航道而对澳大利亚步步紧逼的“三管齐下”计划正在实施。

一、《美国印太战略框架》为何解密?

《美国印太战略框架》于2018年2月制定,阐述了2018年至2020年美国在印度洋、太平洋地区的战略方针。它原来是一份保密文件,由时任美国国家安全委员会亚洲地区高级主管、后来担任副国家安全顾问的Matthew Pottinger加密;公布前于今年1月5日由白宫国家安全顾问Robert O'Brien解密。

从文件格式和内容来看,它属于草稿型的关于大纲和原则的工作性文件,全文共10页。它不是一个单独的文件,倒象是一个更大的文件中的组成部分。

这份文件披露,在《美国印太战略框架》之外,美国国家安全委员会还制定了一个与之平行的《美国对抗中国经济侵略的战略框架》,但后者未解密。《美国印太战略框架》不包括制定文件的背景、讨论过程和执行细节,公布时从第4到第9页有少数文字加黑,但绝大部分内容都对外国公众公开了。

为什么美国即将卸任的川普行政当局突然解密这份保密等级为“秘密”(Secret)、“仅限国内参阅”(not for foreign nationals)的文件?

白宫国家安全顾问Robert O'Brien公布此文件时发表了一个声明,声明说:

现在公布这份文件,旨在向美国公民以及我们的盟友、伙伴沟通介绍美国保持‘印太地区’未来长期自由开放的持久承诺。

美国想达成的一个重要的对华战略目标是“为美国和盟友及伙伴使用军事力量威慑(deter)中国,同时建设在各种冲突中打败中国的能力和概念。”

美国的Axios新闻网报道称,这份文件的公布“揭示了拜登政府将要继承的地缘政治和国家安全挑战”。

笔者以为,解密这份文件,是为了进一步稳定印太地区的局势;川普行政当局意识到,中国对美国的国家安全与印太地区的稳定已经构成了相当程度的威胁,今后美国需要在这一地区继续保持相应的外交和军事部署。

此文件解密后,印太地区的相关国家可以比较清晰地了解川普行政当局已经确定的战略方针,而拜登行政当局今后的相关战略自然也应保持必要的连续性。

二、《美国印太战略框架》的重心何在?

《美国印太战略框架》所涵盖的Indo-Pacific地区的地理范围包括三个部分,即中部印太地区、东部印太地区和西部印太地区。属于中部印太地区的海域和国家是南海、印尼群岛海域、菲律宾和澳大利亚北部海岸,以及新几内亚、密克罗尼西亚、新喀里多尼亚、所罗门、瓦努阿图、斐济和汤加等群岛的周边海域。

澳大利亚对这个地区是非常熟悉的,太平洋战争时期澳大利亚海陆空军为本土国防所参加的战斗基本上就在这一地区。从马歇尔群岛到波利尼西亚群岛的东南部分,再到夏威夷,属于东部印太地区。而西部印太地区包括印度洋的西部和中部,直到非洲的东海岸。

《美国印太战略框架》提到的战略挑战者主要是两个。首要的挑战者是中国,其次是地处印太地区之外的北朝鲜。由于北朝鲜并不具备进入印太地区的实力,所以,中国实际上是印太地区安全和稳定的唯一挑战者。

《美国印太战略框架》虽然涵盖了印太地域的上述三个地区,但东部印太地区和西部印太地区目前尚未面临中国的实质型威胁,所以,中部印太地区才是美国印太战略的重点,而澳大利亚北部和邻近澳洲的印尼周边海域则是美国印太战略关注的一个新焦点。

中部印太地区曾经是太平洋战争的重点作战区域之一,那时澳大利亚的海陆空军曾经与盟军一起,英勇抗击了日军的凶猛进攻。如今,中部印太地区再度成为国际关注的一个重要区域。过去几年来中国在这一地区展现出明显的军事挑战姿态;而《美国印太战略框架》显示,过去两年来美国也一直关注着中国对这一地区的威胁。在中部印太地区,澳大利亚是唯一具有国防实力的国家,也是美国的主要盟友。

三、解读《美国印太战略框架》

《美国印太战略框架》开头就设问:如何保持美国在印太地区的战略优势并促进自由经济秩序,同时阻止中国建立新的、不自由的势力范围,并培育合作领域以促进区域的和平与繁荣?

此文件认为,由于中美之间政治和经济体系的性质和目标之差异,美中之间的战略竞争将持续下去,中国将规避国际规则和规范以获得优势;近期内中国的经济、外交和军事影响将继续上升,并挑战美国实现在印太地区的国家利益之能力。因此,美国要把自己的印太战略同澳大利亚、印度和日本的相应战略契合在一起;与盟国及相关国家密切合作,以防止中国获取军事和战略上的能力。

《美国印太战略框架》指出,美国应当阻止中国使用武力对付美国以及美国的盟友和伙伴,并研发击败中国在各种冲突中的行动之能力和方法。

为此,美国要在印太地区强化具有战斗力的军事态势,以支撑美国的国家利益和安全承诺。按照这一战略,美国将在冲突中否认中国在“第一岛链”范围的制空、制海权;保卫第一岛链的国家和地区,包括台湾;在第一岛链外的所有领域取得支配地位。

这个文件是2年前拟定的,那时中共对中部印太地区的军事威胁还未彰显,所以美国的这份文件比较强调第一岛链相关国家的安全问题,并没有具体勾画出在中部印太地区展开战略防御的设想或布局。

但是,《美国印太战略框架》颇有先见之明,事实上预见到了中国下一步可能的军事动作。自从2020年3月中国宣布其战略核潜艇在南海国际海域建成“深海堡垒”之后,中国海军的核潜艇开始探索它从“深海堡垒”出发、前往中太平洋,以便用潜射核导弹威胁美国的军事部署(参见我去年12月1日的观点《中国对澳大利亚实行经济威胁》)。中部印太地区的形势突然紧张起来。

正是在这样的背景下,美国按照《美国印太战略框架》的构想,在去年12月初宣布组建美国海军第一舰队,其布防区域就是中部印太地区(参见我去年12月16日的观点《中国对澳大利亚施压的真实意图》)。

对这第三项措施,中国并不隐晦它的战略企图。北京的《多维新闻》1月11日发表一篇文章,《中方水下航行器被印尼截获,专家:为中国潜艇秘密绘制航线》,公开介绍了这一举措。据该文介绍,最近印尼在南苏拉威西(South Sulawesi)的塞拉亚岛(Selayar Island)附近发现了中国的无人水下航行器。

1月10日香港的英文《南华早报》称,这些无人水下航行器的标签上写着中科院沈阳自动化研究所,它们可能是在绘制海底地图,为中国潜艇的秘密航行绘制路线。

笔者查找相关信息后发现,近年来印尼在爪哇海的不同海域近岸一共捞到了3艘中国制无人水下航行器,时间分别是2019年3月以及去年的12月20日。

早先的发现地点是印尼领海中段的巽他海峡(Sunda Strait,位于印尼的南苏门答腊岛和印尼首都所在的爪哇岛之间)以及龙目海峡(Lombok Strait),而最近这次捞获无人水下航行器的塞拉亚岛水域位于印尼的爪哇海东段,距离澳大利亚的北大门不远。

《南华早报》引用的关于中国无人水下航行器的母船之资讯过时了。据中国的资讯报道,这种无人水下航行器可能是中国称为“潜龙号”无人无缆潜水器系列中的一种,中科院沈阳自动化研究所为其技术总体责任单位。这种无人水下航行器的母船是“深海1号”和“大洋1号”综合调查船,两者的母港都在青岛。

“深海1号”是中国最大的水下航行器专用母船,属于中国深海基地管理中心;“大洋1号”属于中国大洋矿产协会,主要活动区域是印太地区。“大洋1号”由一艘前苏联的海洋地质和地球物理考察船改装而成,其船尾安装了深海可视采样系统,可实时采集海底微地形地貌图像;它释放的无人水下航行器可以在水下近底自动航行,并采用水声通信技术,从海底高速传输图像。

这种无人水下航行器使用充油银锌蓄电池作动力,每次潜航不会离母船太远;既然这种无人水下航行器已三次被印尼捞获,说明它在潜航中失去动力或失去与母船联系的可能性比较大。

四、军事专家的警惕

美国的《世界新闻》网指出,无人水下航行器是一种机器人,它可以在水下航行,收集海水温度、盐度、浑浊度、叶绿素和氧气水平等海洋数据,以了解海底环境,对海军的部署却具有极高价值,特别可供潜艇舰作战,“海军越懂海水,就更能隐藏他们的潜舰”。

据《南华早报》报道,澳大利亚战略政策研究所(Australian Strategic Policy Institute)国防战略高级分析师戴维斯(Malcolm Davis)就塞拉亚岛附近发现的无人水下航行器判断,它“使用声纳探测海底,以获得准确的海底水深图,并使用传感器了解水中的热条件和声学条件,从而让解放军海军潜艇在不被探测到的情况下获得穿越巽他海峡的最佳机会。”

他认为,通过这样的方式,中国可以确保潜艇以最佳方式部署在南海、印度洋等地。戴维斯还表示,“中国将潜艇派遣到比南海或东海更远的海域——超越‘第一岛链’,或者以一种能使解放军海军收集情报、支持秘密行动或作战的方式,对澳大利亚进行攻击。”

美国智库兰德公司(Rand Corporation)的安全专家希思(Timothy Heath)表达了类似看法。他认为,中国此举很可能是为了收集情报,必要时提高潜艇在这些水域作战的能力;中国可能对在印尼附近水域巡逻感兴趣,这是扩大中国潜艇作战范围的更广泛努力的一部分。

澳大利亚和美国的军事专家们对目前中国战略核潜艇的动向比较了解,而美国的一些外交政策分析人士却没有这样的眼光。

全局代理程序gnos-socksjail

 SOCKSify without leaks.

SOCKSify using tun2socks & netns.

  • netns isolation (Linux network namespaces)
  • DNS over HTTPS (dnscrypt-proxy)
  • profiles with command execution
  • polkit integration

Usage

USAGE:
  socksjail [ -r ] [ -v ] [ PROFILE_NAME | PROFILE_PATH [ COMMAND [ ARGS ... ] ] ]
  socksjail -d PROFILE_NAME
  socksjail -l
  socksjail -h

ARGS:
  PROFILE_NAME    Profile name, stored in /home/user/.config/socksjail/
  PROFILE_PATH    Profile path
  COMMAND         Command to execute, or "null" to keep connected
  ARGS            Command arguments

OPTS:
  -d              Disconnect profile
  -l              List active profiles
  -h              Show help
  -r              Force reconnect
  -v              Verbose output

Install

Put files somewhere, for example /opt/gnos-socksjail, symlink socksjail to $PATH.

Configure

Profiles are stored in ~/.config/socksjail.

Profiles files are simple bash declarations.

VariableDescription
addrSOCKS proxy address: [IP]:PORT
authSOCKS proxy credentials: USER[:PASS]
cmdCommand to execute in jail
preCommand to execute before
postCommand to execute after

Commands are executed using eval to prevent quoting madness.

Running profile uses cache in ~/.cache/socksjail/PROFILE/.


from https://github.com/gnos-project/gnos-socksjail

脸书账号被监控的问题

 如果要避免在脸书被中国当局操作的假帐户监控,或透过保安漏洞偷取个人资料,到底有甚么方法?

李建军:首先,不要在脸书上乱加朋友,现实上不相识的朋友,是没有必要加到朋友清单上,因为朋友拥有的权限,远大于一般脸书用户。加朋友前,请检查一下对方的朋友清单,如果对方没有头像,或者朋友清单的成员身份古怪,例如有不合理地多的巴基斯坦的朋友,你都应该知道,这人很大机会是假帐户,必须严防。

另一方面,脸书其实不属于可以安全与朋友分享你生活一切的地方,因为脸书公司与中国当局的关系一直十分暧昧,如果发生类似日本LINE公司中国员工取得你个人资料的事件,你就十分之危险,因此,如果你想比较轻松分享生活一切,朋友之间用Signal的群组更加安全可靠。至于MeWe,由于其未有比较好的二步认证功能,有安全隐患,并非是一个十分之理想交友和分享秘密内容的平台。

现时对MeWe也好,对脸书也好,你都应该视为一个取得媒体资讯的订阅工具,多于与朋友分享生活点滴的地方,因为中共利用假帐户,不单在脸书和MeWe留下大量假新闻和垃圾资讯,而且利用这些假帐户去监控你的生活,甚至留下一些木马,这才是最大的问题。MeWe和脸书,在自由的美国,或许是安全,但如果你是中国当局的目标人物的话,你必须要十分之小心行事,否则只会自找麻烦。

Django+MySQL博客系统,myblog-by-myminwang

(数据库用sqlite也是可以的。)

py3.6  

使用Django快速搭建博客

环境

  • Python: 3.X
  • Django: 2.0.x
  • MySQL

特点

  • 博客文章 markdown 渲染,代码高亮
  • 第三方社会化评论系统支持(畅言)
  • 三种皮肤自由切换
  • 全局搜索
  • 阅读排行榜/最新评论
  • 多目标源博文分享
  • 博文归档
  • 友情链接
  • 分享、打赏功能

下载

git clone https://github.com/myminwang/myblog.git

安装

pip install -r requirements.txt  #安装所有依赖
setting.py配置自己的数据库
配置畅言:到http://changyan.kuaizhan.com/注册站点,将templates/message.html中js部分换成你在畅言中生成的js。
python manage.py makemigrations
python manage.py migrate
python manage.py runserver

浏览器中打开http://127.0.0.1:8000/即可访问.

from https://github.com/myminwang/myblog

Bubblewrap

Unprivileged sandboxing tool.

Many container runtime tools like systemd-nspawndocker, etc. focus on providing infrastructure for system administrators and orchestration tools (e.g. Kubernetes) to run containers.

These tools are not suitable to give to unprivileged users, because it is trivial to turn such access into to a fully privileged root shell on the host.

User namespaces

There is an effort in the Linux kernel called user namespaces which attempts to allow unprivileged users to use container features. While significant progress has been made, there are still concerns about it, and it is not available to unprivileged users in several production distributions such as CentOS/Red Hat Enterprise Linux 7, Debian Jessie, etc.

See for example CVE-2016-3135 which is a local root vulnerability introduced by userns. This March 2016 post has some more discussion.

Bubblewrap could be viewed as setuid implementation of a subset of user namespaces. Emphasis on subset - specifically relevant to the above CVE, bubblewrap does not allow control over iptables.

The original bubblewrap code existed before user namespaces - it inherits code from xdg-app helper which in turn distantly derives from linux-user-chroot.

Security

The maintainers of this tool believe that it does not, even when used in combination with typical software installed on that distribution, allow privilege escalation. It may increase the ability of a logged in user to perform denial of service attacks, however.

In particular, bubblewrap uses PR_SET_NO_NEW_PRIVS to turn off setuid binaries, which is the traditional way to get out of things like chroots.

Users

This program can be shared by all container tools which perform non-root operation, such as:

We would also like to see this be available in Kubernetes/OpenShift clusters. Having the ability for unprivileged users to use container features would make it significantly easier to do interactive debugging scenarios and the like.

Usage

bubblewrap works by creating a new, completely empty, mount namespace where the root is on a tmpfs that is invisible from the host, and will be automatically cleaned up when the last process exits. You can then use commandline options to construct the root filesystem and process environment and command to run in the namespace.

There's a larger demo script in the source code, but here's a trimmed down version which runs a new shell reusing the host's /usr.

bwrap --ro-bind /usr /usr --symlink usr/lib64 /lib64 --proc /proc --dev /dev --unshare-pid bash

This is an incomplete example, but useful for purposes of illustration. More often, rather than creating a container using the host's filesystem tree, you want to target a chroot. There, rather than creating the symlink lib64 -> usr/lib64 in the tmpfs, you might have already created it in the target rootfs.

Sandboxing

The goal of bubblewrap is to run an application in a sandbox, where it has restricted access to parts of the operating system or user data such as the home directory.

bubblewrap always creates a new mount namespace, and the user can specify exactly what parts of the filesystem should be visible in the sandbox. Any such directories you specify mounted nodev by default, and can be made readonly.

Additionally you can use these kernel features:

User namespaces (CLONE_NEWUSER): This hides all but the current uid and gid from the sandbox. You can also change what the value of uid/gid should be in the sandbox.

IPC namespaces (CLONE_NEWIPC): The sandbox will get its own copy of all the different forms of IPCs, like SysV shared memory and semaphores.

PID namespaces (CLONE_NEWPID): The sandbox will not see any processes outside the sandbox. Additionally, bubblewrap will run a trivial pid1 inside your container to handle the requirements of reaping children in the sandbox. This avoids what is known now as the Docker pid 1 problem.

Network namespaces (CLONE_NEWNET): The sandbox will not see the network. Instead it will have its own network namespace with only a loopback device.

UTS namespace (CLONE_NEWUTS): The sandbox will have its own hostname.

Seccomp filters: You can pass in seccomp filters that limit which syscalls can be done in the sandbox. For more information, see Seccomp.

Related project comparison: Firejail

Firejail is similar to Flatpak before bubblewrap was split out in that it combines a setuid tool with a lot of desktop-specific sandboxing features. For example, Firejail knows about Pulseaudio, whereas bubblewrap does not.

The bubblewrap authors believe it's much easier to audit a small setuid program, and keep features such as Pulseaudio filtering as an unprivileged process, as now occurs in Flatpak.

Also, @cgwalters thinks trying to whitelist file paths is a bad idea given the myriad ways users have to manipulate paths, and the myriad ways in which system administrators may configure a system. The bubblewrap approach is to only retain a few specific Linux capabilities such as CAP_SYS_ADMIN, but to always access the filesystem as the invoking uid. This entirely closes TOCTTOU attacks and such.

Related project comparison: Sandstorm.io

Sandstorm.io requires unprivileged user namespaces to set up its sandbox, though it could easily be adapted to operate in a setuid mode as well. @cgwalters believes their code is fairly good, but it could still make sense to unify on bubblewrap. However, @kentonv (of Sandstorm) feels that while this makes sense in principle, the switching cost outweighs the practical benefits for now. This decision could be re-evaluated in the future, but it is not being actively pursued today.

Related project comparison: runc/binctr

runC is currently working on supporting rootless containers, without needing setuid or any other privileges during installation of runC (using unprivileged user namespaces rather than setuid), creation, and management of containers. However, the standard mode of using runC is similar to systemd nspawn in that it is tooling intended to be invoked by root.

The bubblewrap authors believe that runc and systemd-nspawn are not designed to be made setuid, and are distant from supporting such a mode. However with rootless containers, runC will be able to fulfill certain usecases that bubblewrap supports (with the added benefit of being a standardised and complete OCI runtime).

binctr is just a wrapper for runC, so inherits all of its design tradeoffs.

What's with the name?!

The name bubblewrap was chosen to convey that this tool runs as the parent of the application (so wraps it in some sense) and creates a protective layer (the sandbox) around it.

from https://github.com/containers/bubblewrap

------------------------

bubblewrap的安装

apt-get install -y libcap-dev

(yum install -y libcap-devel)

wget https://github.com/projectatomic/bubblewrap/releases/download/v0.4.1/bubblewrap-0.4.1.tar.xz

tar xvf bubblewrap-0.4.1.tar.xz

cd bubblewrap-0.4.1

./configure --prefix=/usr
make && make install
from http://www.linuxfromscratch.org/blfs/view/svn/general/bubblewrap.html
得到的可执行文件为bwrap.

外國勢力是中國改革手術刀


中共有預謀的清算新疆棉的舊帳,掀起阿拉斯加中美會晤後的第二波「反帝」浪潮。人民日報與外交部華春瑩在第一波搬出八國聯軍,第二波則由新疆黨委宣傳部副部長徐貴相聲稱鴉片戰爭時代,已經一去不復返。

全盤污名化鴉片戰爭與八國聯軍,是國共的共同歷史觀。其實客觀的來看,沒有鴉片戰爭,大清民眾懂得什麼是船堅砲利與奇技淫巧的洋務?沒有八國聯軍,豈能因為立憲而催生出中華民國?沒有這兩次「侵略」,神州大地上可能還蠕動著辮子與小腳的人群。現在卻把這些圖像說成是「辱華」。

為何中國的進步一定要靠老外的武力攻打?這就是中華文化固有的既自大又保守的性格導致不打不相識。第三次外力入侵則是十月革命後馬列主義,由蘇俄向孫中山及中共提供武器與金錢,最後引發中國的長期內戰。

前兩次推動社會進步,後一次把中國引回變相帝制,其過程的漫長,就是因為要將馬列主義中國化,與中國封建文化相結合,形成牢固的文化思想基礎。外國勢力的侵入好比手術刀,但也要看手術是清除還是擴散病毒。

鄧小平的改革開放帶來一九八○年代中國思想界的活躍,但因只開放經濟卻封閉政治,而使改革胎死腹中。漢奸家庭出身而接受民國西方教育的江澤民提出「三個代表」,或有鬆動文化意識之意,但是古板的胡錦濤無法理解,紅二代紅衛兵出身的習近平只熟悉文革與當時宣傳的義和團文化而全盤回歸,形成眼前愚蠢又可笑的大倒退。不過,王滬寧倒是學到了江澤民的「與時俱進」,將數位化與獨裁統治結合起來,鞏固特權統治。這也是為何習近平離不開王滬寧的原因。

中共一再批判創黨元老陳獨秀與張國燾貶低中國農民保守落後只求一個好皇帝的思想農民出身的毛澤東就善於挖掘農村痞子作為他上山落草的主力軍,並打下天下。但這不是進步的革命,而是封建意識與洪秀全拜上帝會的輪迴

要徹底改變這個龐大的封建帝國,外資的進入已證明是無效的,可能還需要戰爭。這是我比較長期的看法。只有強烈觸動帝國外殼,才可促使內部裂解。不必高估中國人的愛國心,中國是盛產'漢奸'的國家。鴉片戰爭的三元里民眾到八國聯軍已經變成「帶路黨」。一九二一年的中共創始人周佛海與陳公博,後來成為大漢奸,毛澤東則是蘇俄大漢奸,也有意投向日本。中國即使禁止跨國時尚名牌進口,必然有「帶貨黨」大量走私進口,而且更是物以稀為貴。

習近平全面出擊,這是一條與西方脫鉤的道路,好得很,讓他去同封建奴隸專制國家「全球化」,只要西方國家因應得宜,看他能堅持多久。

(作者林保華為資深時事評論員,http://blog.pixnet.net/LingFengComment

反仇亞歧視不等於忍讓中國政府 應與戰狼割蓆,保衛普世價值

 在美國歷史上,亞裔經常被視作「恒常的他者」,常常在國家面對失業、經濟危機時被當作替罪羔羊。十九世紀的排華法案與1980年代初,華裔陳果仁在底特律,被埋怨工作被日本車廠搶走的工人當作是日本人,遭到殺害的案件,便是在這個背景下發生。

多年來,美國的亞裔民權團體一直致力爭取消除社會對亞裔的歧見和壓制各種針對亞裔的仇恨犯罪。多年來亞裔在政治上取得突破的例子,也越來越多。去年參加總統選舉民主黨初選異軍突起的楊安澤(Andrew Yang),和剛剛在參議院獲得兩黨一致支持,以98對0票通過出任美國貿易談判代表的戴琪(Katherine Tai),便是很好的例子。

亞特蘭大屠殺案發生之後,亞裔團體隨即動員起來,在各地發起反對仇亞暴力的示威集會。美國從立國開始,便從不假裝自己是一個完美的國家,卻建立了一個民主自由的體制和發展出活力充沛的公民社會,隨時針對國家的不完美,直視問題,爭取國家變得更接近完美

美國和其他民主國家的開放體制,近年卻經常被與美國敵對的獨裁國家利用。例如在這次反仇亞暴力風潮中,中國官方的宣傳機器,便乘機煽風點火,將美國這一年來仇亞暴力上升,歸咎於美國主流媒體對中國批評得太多。《環球時報》在槍擊案一發生後,即在3月18日刊登英文長文、並在官方推特以英語點名《紐約時報》和一名美國資深華裔女記者,批評他們對中國的「失實報導」,是導致仇亞情緒升溫的原因之一,要對阿特蘭大慘劇負責。

過去特朗普政府批評中國政府隱瞞疫情,問責全球瘟疫起源時,經常夾雜一些對華裔和亞裔帶來歧視的種族主義字眼,例如叫瘟疫為「Kung-flu」, 是不可原諒。但我們呼籲停止使用這些種族主義語言,不等於我們要停止向中國政府問責,更不等於要停止批評中國政府在香港、台灣、新疆、南海等問題上的作為。

被「環時」指責有份散布反亞仇恨的《紐約時報》和該名華裔女記者,一直在抵制種族主義上不甘後人,「環時」向他們扣仇亞種族主義帽子,便等於是將任何對中國政府的批評,跟仇亞種族主義等同起來。中共官方媒體的這種偷換概念混水摸魚,十分可恥。然而美國部分亞裔民權領袖和論者,擔心美中對峙升級,會加劇美國主流社會的仇亞情緒,因此呼籲美國停止與中國對抗,改善美中關係,恍惚美中關係惡化的責任,都在美國一方。

這種講法,無論是源於中國政府及其在美國的代理人的刻意散布,還是出於亞裔本身對處境的真心憂慮,其實都是陷亞裔於不義。美國很多人分不清中國政府與亞裔,不等於亞裔要繼續強化這種誤解,還要主動背中國政府的黑鍋,幫北京呼籲大家停止批評。

中國政府對國內人民鎮壓加劇,在世界各地到處凌霸,戰狼外交官的嘴炮越來越嚇人,美國的亞裔不及早與他們劃清界線,吃虧的只有自己。亞裔要防止美中衝突升級導致仇亞升級,最有效的方法,不是成為中共的傳聲筒,勸籲大家忍讓北京,而是放膽站在普世價值的立場,聲討極權政府的反人類罪行


Shadowsocks AEAD加密方式设计存在严重漏洞,无法保证通信内容的可靠性

近日,VLESS协议Xray的作者rprx发现Shadowsocks AEAD 加密方式设计存在严重漏洞,无法保证通信内容的可靠性。具体来说,便是Shadowsocks AEAD防重放设计有缺陷,中间人可以随意对客户端接收的数据进行移花接木或重放,比如对调两条 TCP 连接所返回的数据,达到隐蔽式拒绝服务攻击的目的。

更多详情请参考:

1. 利用防重放机制自动对 Shadowsocks、VMess 等未知流量代理进行“隐蔽式拒绝服务攻击”

2. Shadowsocks AEAD 加密方式设计存在严重漏洞,无法保证通信内容的可靠性

一下是相关issue的转载:

这个问题是昨天发现的,本来我只是想先给 Xray-core 的 Shadowsocks 明文结构加个时间戳以彻底解决对服务端的重放问题。

顺便研究了一下 SS AEAD 的安全性,我脑洞比较大,考虑得比较多,比如是否可以造成 对客户端的攻击,简述如下:

  1. 对于 TCP,Shadowsocks AEAD 往返是完全一样的加密结构,HKDF 的 info 也相同,且响应的加密完全独立于请求
  2. 对于 UDP,同样存在上面的问题(甚至可以与 TCP 杂交),更糟糕的是,UDP 往返连明文结构都是完全一样的

以上“特性”的利用方式太多了,真的很难排列组合完,还是主要说对客户端的攻击:

在不需要密码的情况下,可以随意对客户端接收的数据进行移花接木或重放等操作,使得被代理程序收到的数据没有任何可靠性。

比如将 A、B 两条 TCP 连接返回的数据对调,Shadowsocks AEAD 客户端是无法发现异常的,只会成功解密并传给被代理程序。

一些 SS 实现是全局共用 IV 过滤器,只能在单一客户端且不重启(which is impossible)的前提下防御重放,防不了移花接木。
Shadowsocks 流加密也存在此问题,有兴趣的可以研究一下 SSR 的 auth_chain_* 系列是否也存在此问题。

建议先用 VMess AEAD(实际上它有其它问题,但不是这种严重漏洞),最后感谢某个开发者群成员参与讨论与验证。

需要说明,这里主要是描述存在的漏洞,而对漏洞的利用有很多方式,比如 移花接木、重放、自交、杂交 等,欢迎补充测试结果。

由于 #183 ,我在研究“对服务端与客户端的逐字节重放”,并且取得了一些成果,此时又开了一下脑洞:

如果布隆过滤器被人恶意打满呢?不过可操作性不强,还有太多未知变量。

接着就想到了如题:众所周知,某中间人一直在对未知流量进行重放,导致现在大多数实现都有防重放机制。

而利用服务端的防重放,中间人不需要破坏连接,只需提前发送未知流量的前 32 个字节(或更多),即可使这些代理实质性失效。

不需要封锁任何 IP 或端口,精准阻断未知流量类代理。 某种程度上还是无解的,允许重放又会存在问题。

这个机制简单可行,好消息是,它尚未被部署,坏消息是,一旦部署会很棘手。

其实只会阻断这类协议:未知流量、0-RTT、有重放过滤器。听起来是不是很熟悉?而且并没有封你,是你自己封了自己。 

from https://v2xtls.org/%e9%a2%84%e8%ad%a6shadowsocks-aead-%e5%8a%a0%e5%af%86%e6%96%b9%e5%bc%8f%e8%ae%be%e8%ae%a1%e5%ad%98%e5%9c%a8%e4%b8%a5%e9%87%8d%e6%bc%8f%e6%b4%9e%ef%bc%8c%e6%97%a0%e6%b3%95%e4%bf%9d%e8%af%81%e9%80%9a/

代理协议 UDP全方位透彻解析

 rprx大佬在Xray-core的项目库里又发了雄文,全方位介绍UDP协议以及Xray中的细节,强烈建议一览。最新版请参考原文:https://github.com/XTLS/Xray-core/discussions/237

绝大多数人对代理协议中的 UDP 部分完全没概念,目前很多经验丰富的使用者甚至是开发者一遇到 UDP 就变成小白,导致大多数关于 UDP 的问题悬而不决。鉴于 UDP 正扮演着越来越重要的角色,却没有一篇文章讲代理协议中的 UDP,我干脆写了这篇文章。

这篇文章的目的就是扭转现状,让大家完全参透 UDP,以便更游刃有余地使用 Xray-core 或其它代理类软件。 —— RPRX

简单理解 IP Packet、TCP Connection、五元组、端口、User Datagram Protocol

这些是必须掌握的基本概念,实际上非常简单。

IP Packet:一个个符合 IP 协议的数据包,允许丢包,允许乱序(即接收时的顺序不同于发送时的顺序),属于非可靠传输。

它不是最底层的形式,这里无需深究,重点是知道它的特性。IP 数据包无法直接提供可靠传输,这对应用来说当然是很不方便的,于是就有了面向连接的 TCP 协议,它基于 IP 数据包,但实现了一套连接和可靠传输机制,大多数其它协议直接放 TCP 上面即可。

确定一个 TCP 连接的是“五元组”:

  1. TCP 协议本身的标识
  2. 自己的 IP 地址
  3. 自己使用的一个端口(Port)
  4. 对方的 IP 地址
  5. 对方使用的一个端口

TCP 连接建立后,双方便可从自己的端口向对方的端口发送应用数据,这是全双工的,即双方都可以一边发送数据、一边接收数据。

“端口”这个概念各位都不陌生,它常和 IP 一起出现,但实际上它不属于 IP 协议(没想到吧.jpg),它属于更上层的 TCP、UDP 协议。TCP、UDP 是分别实现了“端口”这一标识方式,所以这两个协议的“端口”不会互相影响。 ping 用到的协议是 ICMP,它也是基于 IP 数据包,与 TCP、UDP 是类似的,但 ICMP 就没有“端口”这个概念。顺便提一句,常见的代理协议只能代理 TCP 或加个 UDP,不能代理 ICMP,所以就无法 ping,有此需求请用传统的 VPN。

接下来终于轮到我们的主角登场了:UDP(User Datagram Protocol)

虽然 UDP 和 TCP 一样是基于 IP 数据包的,但它异常简单,直接完全继承了 IP 数据包的特性:

  1. 允许丢包
  2. 允许乱序
  3. Apparently,属于非可靠传输

你可以这样简单理解:UDP 协议就只是在 IP 协议的基础上加了一个端口机制和校验而已。

对于 UDP 而言,TCP 的“连接”机制也是不存在的,即你申请到一个本地 UDP 端口后,不需要握手/建立连接即可直接向任意 IP 的任意 UDP 端口发送应用数据。 不需要关心对方有没有收到数据,对方也不会告诉你有没有收到数据。(需要指出:存在一种 connected UDP 的中间状态,这只是在发送数据前确定一下目标地址,并没有真正去握手)

UDP 的这些特性催生了三种应用方式:

  1. 注重效率,比如 DNS 查询(不需要先握手)
  2. 注重实时,比如直播、语音等(允许丢包,不需要等重传)
  3. 两者皆有 + P2P,比如一些联机游戏、语音等。注意这就是充分利用了上面加粗的那种 UDP 特性,也是本文的重点。

当然还有另一种对 UDP 的应用方式:基于 UDP 造新的通用可靠传输协议,比如 KCP、QUIC。为什么这些新协议不直接基于 IP 协议而要基于 UDP 协议?因为前者往往需要各级运营商进行设备、系统改造来支持,这显然不太现实,所以 UDP 成了更合适的选择。

那么 FullCone、Symmetric 又是什么?

这两个指的都是 NAT 行为,NAT 的全称为 Network Address Translation,就是你家路由器、各级运营商做的事情:地址转换。NAT 的广泛存在是因为 IPv4 地址不足,另一方面它还可以保护局域网中的设备。

对于 TCP 而言,NAT 行为是什么并不重要,因为 TCP 是双向的流,本机每发起一个 TCP 连接往往会使用一个新的临时端口,从而对应一个新的五元组。

但对于 UDP,NAT 行为可太重要了,因为 UDP 是方向不定的包,使用同一个本地 UDP 端口向不同的目标二元组发包十分常见。

二元组:IP 和 Port,任一不同即视为不同的二元组

那么这种情况下 UDP 数据包到达路由器后,路由器要怎样转发它呢?这就取决于路由器的 NAT 行为了。

其实 NAT 行为多种多样,这里先举例介绍最具代表性的情况。首先有以下情景:

  1. 本地来源二元组 A 向远端目标二元组 M 发若干个包
  2. 本地来源二元组 A 又向远端目标二元组 N 发若干个包

如果由于目标二元组不同,路由器把 A->M、A->N 分别映射成了自己的 A1->M、A2->N(一般为分别使用两个不同的端口发包),且严格限制回包来源,就属于 Symmetric。不难发现,这时候实际上变成了类似 TCP “连接”的通信模式,也是大多数运营商的做法。

而若路由器只看来源二元组 A,始终映射成自己的 A1 向 M、N 发包,就属于 Cone NAT;更进一步,如果 A1 收到了回包,路由器不管来源,直接把这个包发回给 A,就属于 FullCone,也是代理类软件能实现的最佳 NAT 等级、P2P 游戏必备神器(GTA NAT 开放)

上面是简单举例,现实中运营商大概率不会主动分配给你一个公网 IP,也就是说还需要经过层层 NAT,最终得到 Symmetric 很正常。所以为什么你用了代理协议,比如 Xray-core 的 Shadowsocks、Trojan 就可以获得 FullCone?

很简单,因为此时用到的是你的 VPS 的公网 IP,和你本地的 NAT 环境没有任何关系。

这就是为什么要特殊设置 VPS 的防火墙:它默认会过滤返回的包的来源,导致你只能得到某种 Restricted Cone 而不是 FullCone。

对于简单的 UDP 需求比如 DNS 查询,Symmetric 也不是不能用。但对于复杂的 UDP 需求,比如各类 P2P 场景,实现 FullCone 就非常重要了,因为应用程序需要对外使用一个固定的端口,通过这个端口不受限制地往任何目标发包、从任何目标收包(至少别测错了当前的 NAT 类型,后文会说明)。如果你主要是为了打游戏,可以让 UDP 走 SS 协议,因为它拥有原生 UDP 的特性。

这里提一下,Xray-core 正计划着推出更适合打游戏的协议。

Xray-core 和一些代理协议中的 UDP 细节讲解

前面都是铺垫,终于到主菜了。

Xray-core 同时支持 FullCone 和 Symmetric 两种模式,且对协议的支持也非常全面,是很理想的例子。

完美支持 FullCone 的有:

  • Shadowsocks 入站、出站
  • Trojan 入站、出站
  • Socks 入站、出站
  • Dokodemo-door TPROXY 入站(透明代理)
  • Freedom 出站,支持域名解析

仅支持 Symmetric 的有:

  • VMess,因为协议结构不支持,后面会说原因
  • 当前的 Mux,同样是协议结构不支持
  • VLESS(FullCone 在路上了)

众所周知 v2ray 对 UDP 的支持一言难尽,所以 Xray-core 是重构了相关架构和各个出入站的代码,外加反复测试和对很多细节问题的定位、修复,才实现了全面 FullCone 化(除非协议不支持,这种情况会为它准备没问题的 Symmetric,Clash 的 VMess 存在问题)

Xray-core 的 release note 都很有营养,再摘抄一段:

  1. Socks5、Shadowsocks 都是原生 UDP,它们的 UDP 不走底层传输方式
  2. VLESS、Trojan、VMess、Mux 都是 UDP over TCP,且走底层传输方式
  3. HTTP 出入站不支持代理 UDP,Socks 版本 5 之前也不支持 UDP
  4. 这里的 FullCone 指的是 UDP 的 NAT 行为,配置时尤其注意防火墙
  5. 链式代理若要实现 FullCone,一般来说所有环节都要支持 FullCone
  6. Docker 若要实现 FullCone,相关容器的网络模式需要是 Host

补充:Socks、SS 是原生 UDP,套 TLS/WSS 后它们的 UDP 并没有被特殊处理,除非开了 Mux。SS 的 SIP003 插件也不管 UDP。

UDP over TCP 简称 UoT,特别注意,即使你用 mKCP、QUIC 作为底层传输方式,UoT 的也并不会表现出原生 UDP 的那些特性。

v2ray-core 存在的问题

这里主要是解惑,让 UDP 不再玄学。

  1. v2ray-core 架构上只支持 Symmetric 路由,所以你用 v2ray-core 的任何协议都只能 Symmetric
  2. v2ray-core 各出入站对 UDP 的处理和 TCP 是类似的逻辑,不可能实现 UDP 特有的 FullCone
  3. v2ray-core 的 Freedom 出站收返回的包时却没有按 Symmetric 过滤来源,这是玄学的根本原因
  4. v2ray-core 中各处维持 UDP 映射关系的不活动超时时间都很短,所以很容易出现断流等情况

对于第 3 点,简单来说是这样:

  1. 正常的 Symmetric NAT,A 对 M 发过包,只能收到从 M 返回的包,其它的会被过滤掉
  2. 如果中间插一个 v2ray,即使 A 没对 N 发过包,A 也能收到 N 发过来的包
  3. 重点是此时 N 的地址被丢掉了,A 会以为这个包是 M 发给它的,绝无仅有的迷惑行为

这种行为是预期之外的,再加上一些不标准的测试服务器,就会导致能给 v2ray、VMess 测出 FullCone,实际上却完全不起作用。

去年七月底我在某个开发者群内说过这个问题(不标准的测试服务器比如 Google 的那些,以及 v2ray UDP 的迷惑行为),随后 NatTypeTester 的更新只保留了五个标准的测试服务器,并特意验证了返回的包的源地址,测 v2ray 会显示 UnsupportedServer。

此外,Google 的一些应用会先自己测一下当前网络的 NAT 类型,若测出了假的 FullCone,就会导致奇奇怪怪的问题。

NAT 行为进一步探究

相信你已经发现了,NAT 行为并不只有 FullCone、Symmetric 这两种(但这是最极端的两种),实际上 NAT 行为由“发包时映射”和“收包时过滤”这两个行为来共同确定,FullCone 就是两者都最开放,Symmetric 就是两者都最严格,引用一张图:

Fig5 STUN

可以看到,RFC 3489 定义了四种经典的 NAT 行为,v2ray 实际上不属于其中的任何一种,但它最接近 RFC 5780 的 Address and Port-Dependent Mapping 加 Endpoint-Independent Filtering,即图中的 NAT Type 7,只是可能会把返回的包的来源搞错。

Xray-core 的代理协议如何实现 FullCone

这是本文的核心内容,其实原理很简单:把你本地的一个 UDP 端口映射为 VPS 的一个 UDP 端口,并使它们具有相同的效果。

拿一个最简单的场景举例:Socks 入站 + Freedom 出站

  1. Socks 入站收到二元组 A 发来的 Socks UDP 包,其中包含原始载荷与其原始目标 M,路由到 Freedom
  2. Freedom 出站使用一个随机端口将原始载荷发到其原始目标 M,这里认为 Freedom 使用了二元组 A1
  3. 映射关系已经建立,一段时间内 Socks 入站又收到了 A 发来的代理包,Freedom 还会用 A1 发到目标
  4. 同样地,如果 Freedom 的 A1 收到了 N 发回的包,Socks 就会把原始载荷同 N 这个信息一起发回给 A

当然,FullCone 还需要调用方按常理使用 Socks 代理协议,诸如各种 tun2socks 实现一般是没问题的。

下面插一个 Shadowsocks 出入站进来:

  1. 路由到 Shadowsocks 出站,它也是使用一个随机端口,将加密后的“载荷与目标”发到服务端的 SS 入站
  2. 服务端 SS 入站收到了客户端 SS 出站发来的 Shadowsocks UDP 包,解密,剩下的流程和上面没有区别

Trojan 协议的 UDP 也是类似的原理,不同之处是每个来源二元组都会对应一条 TCP 连接,在 TCP 上传输 UDP 的“载荷与目标”。

那么为什么同样是 UoT 的 VMess 却无法实现 FullCone?

根本原因是 VMess 的 UoT 协议结构只能在最开始时传一个“目标”,后面的多个数据包只能传“载荷”而不能带“目标”,服务端会把后续的数据包都发往最开始的“目标”。服务端向客户端返回数据包是同理的,协议结构只有“载荷”,客户端会认为返回的数据包都来自于最开始的“目标”,这和 v2ray 设计上的问题倒是一脉相承的,自带的 Mux 当然也是这样。(VLESS 也没有幸免,不过在改了)

所以对于 VMess、Mux、VLESS,Xray-core 目前是按 Symmetric 来路由的。否则如果是 FullCone 模式,后面的包都会被发到第一个包的目标地址,这就是 Clash 的 VMess 存在的问题,但并不好解决。此外,存在此问题时 VMess 又会被测出 FullCone,假的。

透明代理 TPROXY UDP 的原理

为了让游戏机用上 Xray-core 实现 FullCone,通常需要一个 Linux 设备来透明代理,一个树莓派就可以搞定。

为什么透明代理 UDP 只能 TRPOXY 而不推荐 REDIRECT?

  1. REDIRECT 会修改 UDP 包的目标二元组,并且此时 Linux 没有提供一个配套的机制让代理软件获知 UDP 包的原目标地址
  2. TRPOXY 则完全相反:它不会修改 UDP 包,Linux 还提供了简单的配套机制让代理软件获知 UDP 包的原目标地址

等需要往回发包时,代理软件会先在本地伪造出“返回的 UDP 包的来源二元组”的 socket,用这个 socket 把包发回去(这个原理就是可能会遇到 too many open files 的原因)。相比于其它软件,Xray-core 对这里有专门的优化,更优雅且有更好的性能。

若你在用 Windows 测透明代理的 NAT,一定注意要把当前网络设为 专用网络,这是很多人踩过的大坑,我也踩过。

提一下 QUIC:启用了 Xray-core 的 XTLS 时,通往 UDP 443 端口的流量默认会被拦截(拦截 QUIC),这样应用就不会使用 QUIC 而会使用 TLS,XTLS 才会真正生效。实际上,QUIC 本身也不适合被代理,因为 QUIC 自带了 TCP 的功能,UoT 就相当于两层 TCP 了。

from https://v2xtls.org/%e8%bf%9b%e9%98%b6%e5%bf%85%e8%af%bb%ef%bc%9a%e4%bb%a3%e7%90%86%e5%8d%8f%e8%ae%ae-udp-%e5%85%a8%e6%96%b9%e4%bd%8d%e9%80%8f%e5%bd%bb%e8%a7%a3%e6%9e%90/