-
Notifications
You must be signed in to change notification settings - Fork 82
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
Shutdowns, intensified blocking in Iran since 2022-09-21 #125
Comments
There are some simple network tests that can help find any ways through the shutdown that may exist. During the January 2022 shutdown in Kazakhstan, it was discovered that TCP ports 3875 and 179 worked, when all other ports were blocked. You can try testing these ports in a mobile web browser. portquiz.net is a server that responds with a web page on all ports. Or, if DNS resolution is blocked: Here is an Nmap command to run to test all TCP ports. It should run in 11 minutes or less. scanme.nmap.org does not have every port open, but the ports that are not open respond with a RST, so it can still be useful to detect blocking.
It will be good to know about reachability of DNS resolvers, both of foreign resolvers directly and via domestic ISP resolvers.
On Windows, you can try
I got the address of the resolver 185.49.141.38 from https://dnsprivacy.org/test_servers/; you can try any other resolver. In the output, you are looking for |
The first major shutdown began about 2022-09-21 16:00 UTC (20:30 IRDT) and ended 6 to 12 hours later, depending on the network. It was followed by another shutdown that started about 2022-09-22 12:00 UTC (15:30 IRDT) and ended about 8 hours later. https://twitter.com/CloudflareRadar/status/1573067153036787713 (archive)
IODA links for exploration: https://ioda.inetintel.cc.gatech.edu/asn/44244?from=1663221600&until=1663912799 |
At approximately the same time as the start of the shutdowns, there was a large increase of bandwidth at the Snowflake, so much so that it threatens to overwhelm the capacity of the bridge. (This is the bridge that has already had significant engineering and hardware upgrades for scaling.) This is a graph of send/recv bandwidth at the network interface over the past 5 days: The big crater on 2022-09-22 is where the server was running out of memory and swapping. We are in the process of making some changes to the server in response to the increased load. We have already doubled the number of tor instances, which relieved some of the CPU pressure. We are also testing some performance optimizations and hope to deploy them tomorrow. |
A third outage occurred starting 2022-09-23 12:15 UTC (15:45 IRDT) and lasted about 8.5 hours. A fourth outage started at 2022-09-24 14:00 UTC (17:30 IRDT) and is still ongoing. https://twitter.com/CloudflareRadar/status/1573429947766562830 (archive)
https://twitter.com/CloudflareRadar/status/1573689073268580354 (archive)
|
A friend just ran the
PS: I tweeted about this ticket, hoping more technical folks inside the country would see this and run the tests. I will update the thread if I get any more responses. |
My understanding is that people on mobile ISPs are able to access domestic Iranian services even during a shutdown. It would be helpful to know if there are any domestic DNS resolvers that permit recursive queries of foreign domains and are accessible during a shutdown. The idea is to tunnel through an accessible domestic DNS server to reach the outside world during a shutdown. There are some lists of public DNS servers in Iran: You can test whether the resolvers permit recursive queries using a command like the following. Ideally, you run the command on a laptop that is tethered to a mobile phone, during a shutdown.
If you don't have a tethered laptop, you can do DNS resolver tests from a mobile phone. You just have to change the system DNS setting (instructions for Android, iPhone) and enter one of the resolver IP addresses above. Then open a browser and try to access any foreign web site, like example.com. It won't work, but you can tell from the error message whether DNS resolution worked.
|
Thanks for this.
The fact that both a hostname and an IP address are listed implies that either forward or reverse DNS resolution must have worked. I'm not sure if the test used the hostname scanme.nmap.org or the IP address 45.33.32.156, but even if you only give an IP address, Nmap will do a reverse lookup to get a hostname if possible. You can test reverse resolution using the
It would be interesting if reverse but not forward DNS worked during a shutdown. I don't know of any tunnels that use PTR queries and PTR records, but it's not impossible: dnscat2 can use constrained types like TXT, MX, CNAME, A, and AAAA. But let's try to get more confirmation about whether forward recursive queries work or not. |
New OONI report is out: https://ooni.org/post/2022-iran-blocks-social-media-mahsa-amini-protests/ A whole lot of things are blocked now. The networks I had access to are all at 0% connectivity based on what CloudFlare Radar is showing 😣 |
Besides the shutdowns which started this thread, the report covers:
The blocking of DoH resolvers is interesting to me. It should be superfluous to block DNS resolution if endpoints are already blocked. Maybe the censors are going for defense in depth. Maybe encrypted DNS was being used for tunneling. Maybe it exposes a weakness: some services are blocked only by DNS and not by, e.g., TLS SNI filtering, therefore it is required to block secure DNS. Or possibly there's no specific intention behind it, just a setting on some firewall hardware. |
The blocking of the application stores creates a typical chicken-or-egg problem in censorship circumvention. That is, users need a bootstrapping to get access to the application stores so that they can download other circumvention tools. Fortunately, the bootstrapping channel doesn't have to be very robust or censorship-resistant; it can be a low bandwidth, high latency channel that only works temporarily. Some bootstrapping channels include: For Android, getting users an APK file should be enough for bootstrapping. It can be done by sharing the APK files via some low profile channels, for example hosting an APK on an uncensored website and share users a link to it. For iOS, users may have to use the Apple App Store to download the software. One may want to take the advantage of iOS's built-in VPN client that supports IKEv2, IPsec, and L2TP protocols:
|
I probed all DNS servers from https://public-dns.info/nameserver/ir.html for the IP of
The ASes that returned NXDOMAIN are probably able to access external DNS resolvers. Edit: In my initial test I was reusing the same domain, which could trigger cached results. It's now using a unique domain per query. |
Looking at Cloudflare radar: ASes not subject to curfew:https://radar.cloudflare.com/asn/58224 https://radar.cloudflare.com/asn/12880 https://radar.cloudflare.com/asn/49666 https://radar.cloudflare.com/asn/50057 AS that was added to the curfewhttps://radar.cloudflare.com/asn/56402 ASes subject to curfew |
Irancell (owned in part by MTN Group) and MCCI, a state-owned entity, account for over 60% of Iranian mobile phone users, if not more. The internet shutdowns are clearly aimed at mobile networks to stop the protestors from mobilising and organising (and sharing information too). |
Hi there 👋 I found this thread a couple of days ago when a friend of mine sent me @fortuna's tweet. Since then I have been running some tests (including the port scan). The nmap results would be irrelevant since we haven't had a shutdown since I've started testing. But in the past couple of days I've been witnessing some strange behaviour. I first noticed that my VPN client was not detecting my location properly a couple of days ago. My initial thought was that this is an internal issue (caching my IP from the other VPNs I've been testing). Tonight I realized it's much more than that. Right now, on an AS58224 (TCI) connection I'm getting the following results:
Note that the Geolocation and AS detected by Cloudflare is not consistent with the other results. Switching over to AS197207 (MCCI) using an iPhone's hotspot returns the following results:
On the iPhone using the Net Analyzer app shows two 10/8 IPs as DNS servers when using MCCI cellular and 5.200.200.200 when using TCI over Wi-Fi. The DNS Leak tests return a variable number of servers (between 20 to 60) a few of which (2 or 3) are usually the correct one. But based on these, I'm either getting service from Layer 3, Cloudflare, Google, Vodafone or Lumen and am located anywhere from the UK to Japan! Anyways, thought this might be of interest. I'm also curious to know what you think about this situation. p.s. all tests were run on a fresh linux VM with a dedicated USB Wireless card and no manual network configuration. |
@Fardinak, it's not your system or even ISP's problem. It's called anti-sanctions service, but in reality, it's just bandwidth throttling service by DCI. Do you remember the GitHub problem 8 months ago? it's the same technique. they reroute and tunnel specific (/32) IPs. |
Right on schedule. As reported by Cloudflare Radar there is a shutdown in progress on Iranian mobile carriers. Here is the portscan for AS197207 (MCCI):
I'm most curious about AS44244 (IRANCELL) since CF Radar doesn't show a complete shutdown on this AS for the past couple of cycles. Here is the portscan results from AS44244 (IRANCELL):
Definitely not what I expected. @xhdix wow, I was not aware of these "anti-sanction services"! TBH I've almost never disconnected my VPN during the past five years, specially since the 2019 shutdown. Basically anything I need for my work or life is either censored or sanctioned! |
@Fardinak that's very helpful information. It looks like those 6 ports may be useful for circumvention on MCCI, but it looks like we're out of luck on Irancell. I wonder if DNS can get out there. |
Any tests you'd like me to run? I'm about to setup a VPS to try a bunch of protocols over these ports. SSH not being filtered gives me a lot of hope. Please let me know if you have any suggestions. |
Thank you for running these port scans. My interpretation, however, is that the results unfortunately do not reveal anything useful. The MCCI scan shows no clear signs of blocking: all ports except a few were responsive (6 ports returned SYN/ACK, but 61,883 returned RST; i.e., they were not blocked). The Irancell scan looks like total blocking, with no responsive ports; i.e., it's not a case like in Kazakhstan where a few ports were left unblocked.
The way to interpret this is not only to look at the 6 open ports (they are simply the 6 ports that are open on the server; a port scan from anywhere would find the same open ports), but also the part
|
@Fardinak I hope to be able to set up a DNS tunnel for testing at least; but I'm also pretty swamped with the Snowflake bridge amid all the new users and other aspects of this blocking event. If you are technically inclined and want to try it yourself, this is the source code and installation instructions: The tunnel was designed to run over encrypted DNS, but during a shutdown you may only be able to access plaintext UDP port 53 DNS resolvers (you can try the likely accessible resolvers from #125 (comment)). The tunnel can work with a plaintext UDP port 53 resolver (use the I'm aware of some third-party Android apps that use the dnstt code. I have never used them and I cannot say whether they are safe. This is not an endorsement. But these third-party apps could provide an easy way to test whether a DNS tunnel can work at all. You will need to activate "dnstt" or "slowdns" mode and enter the resolver you want to use. These are the apps I know about: |
@wkrp thanks for all the info 🙏 I've had many people contact me during the past couple of days for recommendations on circumvention apps and tactics. But the truth is that I'm running low on options myself. Basically nothing works on mobile carriers. I've only succeeded in using multi-hop ss tunnels (using v2ray) and even then there isn't much bandwidth to work with. I'll keep you posted when I get a chance to test a DNS Tunnel. |
I posted information about troubleshooting Snowflake connectivity and alternate bridge lines to try at #131. |
At #131 (comment) it was observed that certain DNS names used by Snowflake did not resolve during a time of shutdown on the Irancell network. I do not know whether this is an isolated incident or whether it is typical. I do not know whether only those names failed to resolve, or if any other name also would have failed. I would like to know whether anyone else has had the problem of certain domain names not resolving. Are you able to resolve the name stun.uls.co.za? What about www.example.com? It may be something that can be worked around by changing the system's DNS server, possibly to one of the domestic recursive resolvers @fortuna found in #125 (comment). |
Team CommUNITY has a blog post from October 11 that summarizes the situation and lists resources. Internet Freedom Tools, Resources & Actions to Support Iran's Feminist Uprising
|
WEPN is maintaining a document of censorship observations from Iran. One of its topics that we have not discussed on this thread yet is speed throttling.
|
things got worse now only multi-hub ssh tunneling works on mobile carriers |
It seems TLS to DigitalOcean is being blocked on many networks. My probes get a timeout after the TCP connection is established: However, TLS to DO works from AS41620 (IUSTCC-AS - Iran University Of Science and Technology): TLS to Hetzner Finland server seems to work fine from multiple networks: If you want to use TLS for circumvention, try different providers. Update: Testing the connection to DigitalOcean again with SNI seems to work: On Irancell: |
VPNs completely disabled |
There's been some progress in diagnosing TLS fingerprint blocking, as a result of investigating Snowflake connectivity problems. There is strong evidence of an attempt to block the native Go crypto/tls fingerprint, but not all native fingerprints produced by Go programs are blocked. There are (so far) two known dimensions that matter:
These 2 binary dimensions (AES-GCM priority / ChaCha20 priority) and (min = TLS 1.0 / min = TLS 1.2) give rise to 4 combinations, and available evidence says that only one of the combinations is blocked:
The right way to deal with TLS fingerprinting is to use some form of TLS fingerprint camouflage, such as the uTLS package for Go. uTLS has already been added to trojan-go, and Snowflake. But if you are not able to adopt such a measure in the short term, recompiling client programs with go1.18 may buy some time. |
@wkrp , thanks for update. I have some news that the following is not working in Iran. But it's just based on one user. |
Thank you for the report. Are you using Tor Browser 11.5.4? The Another thing you can try is combining the alternative AMP cache rendezvous |
@wkrp Will test AMP too. |
@wkrp |
Orbot for Android 16.6.3-BETA-2-tor.0.4.7.10 with utls enabled, now available here: (arm64 direct APK: https://github.com/guardianproject/orbot/releases/download/16.6.3-BETA-2-tor.0.4.7.10/Orbot-16.6.3-BETA-2-tor.0.4.7.10-fullperm-arm64-v8a-release.apk ) This uses "utls-imitate=hellochrome_auto" - we will add the other options and ability to customize/select in the next update. This release also has the ability to get Snowflake logs directly from the log window (enable Prefs->DEBUG log, tap on status messages to open log window, tap on snowflake icon to show snowflake log, then share!) |
I tested in Iran. It didn't work
…On Thu, 20 Oct 2022, 20:49 Nathan Freitas, ***@***.***> wrote:
Orbot for Android 16.6.3-BETA-2-tor.0.4.7.10 with utls enabled, now
available here:
https://github.com/guardianproject/orbot/releases/tag/16.6.3-BETA-2-tor.0.4.7.10
(arm64 direct APK:
https://github.com/guardianproject/orbot/releases/download/16.6.3-BETA-2-tor.0.4.7.10/Orbot-16.6.3-BETA-2-tor.0.4.7.10-fullperm-arm64-v8a-release.apk
)
This uses "utls-imitate=hellochrome_auto" - we will add the other options
and ability to customize/select in the next update.
This release also has the ability to get Snowflake logs directly from the
log window (enable Prefs->DEBUG log, tap on status messages to open log
window, tap on snowflake icon to show snowflake log, then share!)
—
Reply to this email directly, view it on GitHub
<#125 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF26MY77M5YZXJXZZYC4ZYDWEF5IPANCNFSM6AAAAAAQSTBP2Y>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Thank you. Did you enable Snowflake under the Bridges section on the main screen? Otherwise, if it isn't too much trouble, can you try the following steps, to get some more details from the Snowflake log?
then post that output here, or send the output of that to my email? nathan@guardianproject.info |
I sent an email
I requested a new bridge by email and added it.. when the program started,
it got stuck and crashed. I think the beta version is broken for me
…On Thu, 20 Oct 2022, 21:56 Nathan Freitas, ***@***.***> wrote:
Thank you. Did you enable Snowflake under the Bridges section on the main
screen?
Otherwise, if it isn't too much trouble, can you try the following steps,
to get some more details from the Snowflake log?
1. enable "Debug Log" near bottom of the Settings menu
2. restart Orbot
3. tap the status line (where it shows the "starting..." etc messages)
4. tap the snowflake icon next to "Log"
5. tap the share button
then post that output here, or send the output of that to my email?
***@***.***
—
Reply to this email directly, view it on GitHub
<#125 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF26MY2ZKOXPUWYUNBZUGKDWEGFEFANCNFSM6AAAAAAQSTBP2Y>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Received the log. Thank you very much. If you have a chance to try Snowflake in Orbot instead of obfs4 bridges, please do. |
I thank you for trying Free Internet
Whenever you need my help, I am at your service
I don't see the Snowflake option in the bridge section
…On Thu, 20 Oct 2022, 22:22 Nathan Freitas, ***@***.***> wrote:
Received the log. Thank you very much. If you have a chance to try
Snowflake in Orbot instead of obfs4 bridges, please do.
—
Reply to this email directly, view it on GitHub
<#125 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF26MY76VL3AOLE4VBUJKWLWEGIIVANCNFSM6AAAAAAQSTBP2Y>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
You sure? It is very easy to find in Orbot. At the main page there is "Use Brdiges" option: and if you tap on it, there are 2 snowflake options: 1. fastly 2: AMP. Choose the first one and go back to main page, then press Start. |
On older devices, Android 9 and before, we don't support Snowflake, and those options are not displayed. We are looking into if we can remedy that, but there were issues with the Go code crashing. |
To whom it may concern > |
Any other n==bie task in which I Might be helpful? ;-)) |
How can i find witch UDP ports are open and available in Windows OS. TOR doesn't work in Iran now, L2TP VPN works on most ISP. |
Maybe government monitor this post so revealing our information maybe against what we are trying to do. |
There is a new report on network effects in Iran since September 2022. It is a collaboration of many contributors: OONI, IODA, Measurement Lab (M-Lab), Cloudflare, Kentik, Censored Planet, ISOC, and Article19. https://ooni.org/post/2022-iran-technical-multistakeholder-report/ Summary of key topics:
|
Had a lot of effort to write this report |
There are reports of shutdowns in some mobile ISPs in Iran since about 2022-09-21 16:00 UTC (20:30 Tehran IRDT, about 8 hours ago). I don't know much technical detail yet.
IODA doesn't show a major drop in the country as a whole:
https://ioda.inetintel.cc.gatech.edu/country/IR?from=1663135200&until=1663826399
But you can see an effect in certain ISPs, like IranCell here:
https://ioda.inetintel.cc.gatech.edu/asn/44244?from=1663135200&until=1663826399
It may be a good idea to review #102, lessons from the January 2022 shutdown in Kazakhstan, and for example do some port scans to see if there are holes in the shutdown.
If you experience a shutdown and are able to get online for even a little while, Access Now has a form to report your experience:
https://www.accessnow.org/keepiton/#take-action
https://forms.gle/pUh6EPwwtkD65BDY6
Some Twitter posts:
https://twitter.com/OliverLinow/status/1572698570498920449 (archive)
https://twitter.com/DougMadory/status/1572657304335716353 (archive)
https://twitter.com/CloudflareRadar/status/1572662811951771648 (archive)
The text was updated successfully, but these errors were encountered: