China probes on Iran VPS after GFI piercing

Information in regards to the TCP PORT PROBES from China that hit our server in Iran when testing TCP ports.

The companion article: https://blog.thc.org/the-iran-firewall-a-preliminary-report

Our goal was to find the most reliable method to get network traffic out of Iran during times of severe disruption. For this we needed to gain a better understanding of what ports and protocols are filtered and in which direction.

It was a day during severe disruption - the most severe we have witnessed (and not witnessed since). A golden hour for any researcher.

Our task was not to find probes from China but the unusual TCP packets and the precise timing caught our attention. We observed the probes in tcpdump. At that point (and considering our goal) they were more of an annoyance. At this point we did not know that those probes were from China. We only did a geo-location lookup after our assessment. We focused back on our task (to find a most reliable way out) while the Infra was so beautifully unstable and disrupted.

Only after our assessment did we check the location of the IPs that probed our servers. The 2 IPs still showing on our console were 122.243.85.105 and 42.224.225.213 (both from China).

• Our VPS was Located at Noyan Abr Arvan in Tehran.
• IP address of our server is obfuscated to protect the admin
• Times are in UTC (just after 2pm). The date was Wednesday, 26th of October 2022.
• VPS is the server in Iran. FREEDOM is the server outside of Iran.
• GFI is a synonym for Great Firewall of Iran.

The detail and timing of the probe:

During our exercise we initiated TCP connects from FREEDOM to VPS on various TCP ports. It was manual labour (netcat & tcpdump rather than nmap).

We used fresh listening ports on VPS (no service previously ran on these ports) and FREEDOM never before connected to the VPS (an unknown IP<->IP relationship from the GFI's perspective).

One of the tested ports was Port 23.

netcat -vnlp 23 and tcpdump -n port 23 were running in the console on VPS.

The TCP connection was initiated from FREEDOM (also using netcat) to VPS (Iran).

On FREEDOM the 3-way TCP handshake completed (SYN-ACK received, last ACK sent). On VPS the 3 way handshake did not complete (the last ACK from FREEDOM to VPS never arrived). Both ends were in a different TCP state (EST on FREEDOM and SYN_RECV on VPS). We assumed that this was due to the active nature of the GFI: To wait for application layer data before allowing both peers to connect.

The netcat on the VPS remained in listening mode (because the kernel never managed to complete the 3-way handshake and thus never notified netcat that a connection was happening.).

Within seconds did we then observe (in tcpdump) another TCP connection on the same port. That 3-way handshake fully completed (when ours did not).

14:14:59.093363 IP 42.224.225.213.22643 > 888.1.2.444.23: Flags [S], seq 1086259129, win 29040, options [mss 1360,sackOK,TS val 993064057 ecr 0,nop,wscale 5], length 0
14:14:59.093454 IP 888.1.2.444.23 > 42.224.225.213.22643: Flags [S.], seq 4259828992, ack 1086259130, win 65160, options [mss 1460,sackOK,TS val 2124211512 ecr 993064057,nop,wscale 7], length 0
14:14:59.350564 IP 42.224.225.213.22643 > 888.1.2.444.23: Flags [.], ack 1, win 908, options [nop,nop,TS val 993064313 ecr 2124211512], length 0

We equally tested port 24 and some high ports. The results were identical. We did not know (at that point) that those probes are from China. We then continued our assessment to circumvent the GFI with different methods.

We looked up the Geo-Location for the source of the probes after:

122.243.85.105 CHINA / Zhejiang - China Network Backbone
42.224.225.213 CHINA / Henan    - China Unicom Backbone

Some notes and gut feelings

• The CHINA's probe's 3 way handshake completed when ours was 'held in limbo' and did not complete. My gut feeling is that we got probed by an active component of the GFI to determine the service running on our VPS.
• It was a rather quiet time in regards to stray network traffic. It was a 'blackout' and the tcpdump did not miss-fire or showed any other traffic but OURS and the PROBE's.
• We were not able to reproduce this the day after. Perhaps we have to wait until there are severe disruptions again.
• I'm not from Iran (I'm german). I have never been to Iran. I have never done business with Iran. I dont even know anyone from Iran or have ever spoken to anyone in Iran until a week ago. I was intellectually interested how the GFI works and I was appalled how the illegal Regime in Iran is treating the people and the Regime's blatant disregard of the UDHR - likely the most important treaty that Iran ever signed.
• I now know some people in Iran. Mostly admins and IT geeks. They are smart. Their cleverness goes beyond normal. It's more than what you learn at Universities. It's true passion. There is a loose hierarchy of who is more elite. It's a tight knit community - everybody knows or has heard of each other. They all want their country back (and oust the illegal Regime). Running a GFI takes experience, skills and constant (almost real-time) maintenance and adjustments. I cant fathom that a large enough group of regime-loyal IT-Admins exists who would betray their people and their country with such effect (nearly real-time) - and all this without any of the other Admins and Geeks knowing about them. If I were the illegal Regime of Iran then I would not task the people who rebel against me to run the GFI. It seems far stretched that the GFI is run by IT Admins and Geeks from Iran....

About me: I've 30 years of experience in network evasion and network protocol (starting with CCIT5). I've been part of various IETF working groups (IPSEC, TLS, DNSSec, ..) and designed various network communication and security protocol. I've broken some as well (GSM, Tetra, ..). Some people would describe me as a hacker. I enjoy curious problems.