-
Notifications
You must be signed in to change notification settings - Fork 535
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[One Idea] IP Geolocation Based Filtering #206
Comments
Or just switch to the new Shadowsocks 2022 protocol (#196). Shadowsocks 2022 provides full protection against replay and probes. My implementation also allows you to configure how invalid requests are handled. |
两件事:
|
@dev4u What kind of custom header do you have in mind? Should subsequent reply still be random gibberish? Maybe instead of adding an option to allow |
Thanks both for your comments. @dev4u, my testbed has been running for 2 weeks. Haven't noticed anything like what you described. Actually I have a doubt about that. Such behavior will definitely compromise any normal service based on IP Geolocation. And I cannot see what's in it for those ISPs, other than bringing themselves troubles. Perhaps the IP Geo info you used are not accurate enough? Thanks |
@database64128 我对于抗监%%管的立场是:与其堵不如导。这里说的“导”,有疏导、引导两层意思。 对于监&&管者来说,他们希望知道端口提供什么服务。对于探知的请求,如果只是阻断、返回随机数据,这对他们识别服务,毫无帮助,也不能断了他们的念想而继续探知……如果返回一段特定头部的数据:例如返回voip、rtsp、ldap、ssh…特征头部数据,可以有效降低监管者对端口的好奇、探知。 实现了fallback,可以返回特定的头数据,对于端口服务伪装性,也会有很大的帮助。 |
这可能是幸存者偏差,不过只要用这个方案,肯定会受ip geo准确性影响使用体验。 |
@sh4run
|
@dev4u Counterpoint: The censor can also block the port when the actual traffic does not match probing results. For example, the traffic over a Shadowsocks TCP port looks nothing like TLS. But if you configure your server to fallback to a TLS server, probing would determine the service to be a TLS server. The censor may then decide to block the port on the basis of protocol mismatch. Nonetheless, fallback might still be useful in some scenarios, and it’s trivial to implement. |
@dev4u 谢谢分享。为了抵抗封锁,大家也是绞尽脑汁,各显神通 :-)
@database64128 @dev4u My gut feeling on this is, when there are too many unknowns, doing nothing is somehow better than doing something. |
The current default is quite passive too. I just want to give users more options, just in case you know. And it’s quite a bit of fun to brainstorm, debate, and come up with these options. 😄 |
@database64128 是的,但还有个重要的原因,是有些“布道”者,随便不知哪抄的,提供的方案,让很多一知半解的追随者盲目跟从,这也是要命的。 针对你说的,有人实现了个方案可能可以避免,我也觉得挺有意思。一个叫sh*dow tls,他将请求建立连接的握手包,转至个https站点处理。在完成https握手后,服务端再将后续真实的payload接管回来…… |
Some update: my testbed is blocked by GFW today. It seems there is a grand operation today. I didn't find any leaked probes in the log. So it appears to me how to block or handle the probe/replay is not the key issue. When one receives probe/replay, it means GFW has already put it into its attention list. The probes/replays are actually an alert you are being watched. How to avoid getting those might be the key. Proprietary protocol may be a choice. |
@dev4u Fallback has been implemented in database64128/shadowsocks-go@bfe0270, and can be enabled by specifying an |
收到!同时我也发现,你紧接着也commit了返回自定义头部数据的功能💪。 对此,我也有一个疑问一个建议:
功能的雏形是出来了,希望有关注的小伙伴们,别不小心又跑偏了。 |
|
Hello guys, As I found earlier, GFW probes are likely indications that this IP(vps) is being watched. The key point to pass through GFW is not to get its attention instead of how to handle probes properly. Based on that, I added some flavors to shadowsocks stream to something below. I am trying to create a stream w/o any obvious pattern.
More details can be found here: https://github.com/sh4run/sss#protocol The test result is pretty good. My testbed has been online for 2 weeks with 40G+ traffic. Compared with SS, much less GFW probes are received. No probes are received in that the last 5 days as long as I don't play youtube 4K video. Just to share a new idea. Comments and thoughts are welcome. Thanks |
你在方案中加入了用证书做安全手段,这个我觉得是不错的做法,但仍需要通过时间来验证有没短板。 |
Hi dev4u, Thanks a lot for taking a look into this and giving me your feedback. I guess I didn't give a description clear enough. What SSS does are:
By doing so, SSS is trying to hide itself from any pattern match in GFW.
SSS is trying to make its frame to be with no obvious pattern (either length or content). So that it would be difficult to use existing pattern match in GFW to detect SSS. And the test results show:
Of course due to the lack of samples, it is hard to tell how effective this protocol is at this moment. But I think it is too soon to say it is a survivor bias too. Thanks again. |
咱们换种思路。 你描述那么多优点,其实我想知道,如果你是gfw,你可以用什么手段来干扰你的数据?你的协议其实跟ss已经没有半毛钱关系,现有的策略,为什么会觉得对你的sss仍有效呢? 同时我也交流一些我对gfw的心得看法,可能有点跑题,不中听当我瞎掰。 gfw已经从单一通过数据特征分析,转变为通过立体行为来分析、判定流量的机制。 举个例子,一个服务,周期性产生流量,流量长度一致且不大。这种流量一般是心跳包或者检测包。对于gfw来说,根本不用理会里面是什么数据。 我只是举例子,不用对号入座。 |
Thanks for your reply. It is true the upstream (client->server) format is changed a lot in SSS. The downstream format is changed too, but much less. Yet from the software perspective, the whole architecture of SS is not changed. All changes are limited to the processing of upstream/downstream traffic: adding and removing scramble code. That's why I call it scrambled Shadowsocks. The purpose of SSS is to hide itself from the GFW detection that works for SS. So if what works to detect SS doesn't work now, that means SSS achieves its design goal. The GFW detection methods that I can think of might include:
SSS is able to handle 1) & 2) now. It is possible for SSS to handle 3, but it requires some architecture changes. I will leave 4) out as I don't have a clear picture about that part. SSS is never designed to be a once-for-all solution. But what I believe is true is, the more difficult and expensive to detect, the bigger chance for this technology to survive. Thanks again. |
Probes and replays from GFW are threats a shadowsocks instance has to face every day. This feature introduces a new mechanism to filter out those malicious packets. Tests show GFW uses IP addresses all around China (oversea addresses are spotted as well) as source in those probes and replays. This is an effective method to undermine any blacklist at shadowsocks side. But this also gives a good chance to screen most of them based on IP geolocation if geolocation of the actual client is known for certain. This feature is not applicable in large business use cases where the shadowsocks service is provided to unspecified individuals.
A draft implementation can be found here: https://github.com/sh4run/ss. Tests show it can filter out 95+% probes & replays.
Comments and thoughts are welcome.
The text was updated successfully, but these errors were encountered: