Iran ISPs use plain DNS to drop TCP connections and block proxies #156
Comments
|
Hello, Interesting! Some intuition behind your description may be true; however, we need to be sure that we are on the same ground. As far as I’m concerned, what you state is that the main FW(ISP) shall check the flow of information including DNS requests in plain text. If the connection request is established with any proxy instead of the IP stated in DNS response message saved earlier, then the connection will be torn down. Besides the computational cost of this method, what happens if the DNS requests are also tunneled to the proxy? We can normally check it via DNS Leak or 1.1.1.1/help. If the DNS requests are sent over the proxy, then the initial DNS request will not be visible to FW (ISP), and the above-mentioned scenario will not occur (the connection to the proxy will not be noticed!). Do you affirm this case? Valid assumption? With Xray, and V2ray, I can confirm that all DNS requests are sent over the proxy. If yes, why this solution does not work based on what you described above? Moreover, Would you elaborate more on the below lines? I don’t seem to parse it!
|
|
Thanks someone else saw the weirdness here, it's hard to produce it on someone who is tech savvy enough, the problem with xray part was that i had a lot of people using my servers, and im connected and talking people running servers, but the problem is some(not all) android phones went dark first, so i tought its TLS FP which i expected, some of them were that but not on all net providers, so i randomly suggested them that change some dns stuff, i didn't know that android still has no good dns features, so they picked up weird methods like turning phone on/off and other weird things that looked unrelated, i didn't take that as dns flush but they could connect again for like one week, the others didn't tried for dns could not with same server and network. in terms of strategy for blocking all solution, this and tls fingerprinting can block both those V cores and those browser stacks mitigations of newer solutions. |
Here:
In this first case it is easy to configure the client to pass the DNS traffic through your proxy. Also, I could not understand your example in "Ubuntu download" case. |
|
@arandomgstring So let me also clarify these things:
|
|
@alirezaac
No, it is stateless (they don't care about flow of information) and honestly, I think it is computationally as heavy as TLS fingerprint blocking, maybe a little more but not much. Note that ISP have no idea whether you have established a connection through a proxy, or directly to a website; they are totally the same on packet level (as long as you use TLS + WS I assume). What they do is a bit different I presume. Let me elaborate a little:
Note that DOH of 1.1.1.1 (cloudflare) is blocked; just its plain text mode works. Same goes for Google DOH. You can simply test this by going to chrome://settings/security?search=dns and setting Use secure DNS 1.1.1.1 in Chrome. 1.1.1.1/help won't open. meaning this DOH is blocked. You can do the same in Firefox and get the same result. Even better, I set 1.1.1.1 on IPV4 settings of my user network and checked Wireshark. All packets sent to 1.1.1.1 were blocked :). It seems that sometimes Cloudflare and Google understand this, and they switch to plain mode automatically, but I haven't seen such a thing personally.
Correct. There is a catch however. When you use an application, along with an arbitrary V2ray client (for example V2rayN), the application itself will "resolve domain address" before sending its packets to Socks5 proxy (i.e V2ray Client). I have already checked this in Wireshark, you can check it too; it is easy. This is indeed the case for browsers. V2ray Client may resolve domains on proxy server, but note that it only does so if and only if it receive a domain in the first place! (not an ip). If you set socks5 on Firefox to v2rayclient, it will still resolve domains with ISP DNS resolver, DNS look up won't go through the tunnel. Fortunately in Firefox you can simply set "network.proxy.socks_remote_dns" to true and by doing so you will actually resolve domains on proxy server. If you don't they will be resolved on ISP dns resolver, even if you have set V2ray Client to resolve domains remotely. That said, you don't have the luxury of this option on other applications; Firefox has it. What about a game?. I have tried Proxifier with its Name Resolution mode to force resolution of domains remotely. Unfortunately, it does not work, perhaps because we are dealing with a local socks5 proxy which is chained to another proxy on VPS server. Now comes the fun part. On smartphone devices we are totally busted, because we are essentially proxifing all traffic, except DNS look ups. I don't have a rooted android device so I cant check packets (pcap doesn't work with another vpn), but from what @alirezaac says, it seems to be indeed the case.
What I am trying to say is, they don't understand if you have established a connection to a proxy, or you are simply downloading a file. If you don't obey their rules, they will block the connection temporarily. If a connection get blocked a few times they assume its a proxy and it will be blocked on a longer period, maybe permanently.
Neither (Or maybe the first case if I understood you correctly), really. If you could send DNS request to proxy tunnel, everything would be fine. In practice however, many applications (even browsers) do the DNS lookup themselves outside of proxy tunnel. After DNS resolution they will use proxy tunnel, which is too late. And no domain-fronting doesn't work as far as I am aware. Not only Cloudflare block it (it gives Gateway Forbidden message) but also Iran ISPs have blocked many Cloudflare IPs in the first place. My setup is VLESS + TLS + WS + NGINX with a real website on front. As for Ubuntu case, what I meant is you can download anything from any server outside of Iran, then If you try to access youtube or something (if you manage to get its real IP not just a bogon IP) and not connect to it, your download will stop abruptly. So they can't distinguish between a proxy packets, or simply downloading a file. They just block whatever you have.
No and No. If anyone has any idea how we can force DNS look ups for all applications through proxy on either of Windows, Linux, Mac, Android, IOS, they will be more than welcome. Maybe there is a V2rayClient that can do that? Tell me about it. Thank you. |
|
@arandomgstring |
well im having like a 1 or 2 minutes of ssl handshake error until GOOGLE DOH anycast change the ip and relays the dns, which i use the self hosted dns for now to be one step ahead of google blockage in my isp. and that TUN is not handling dns specially in mobile devices. |
|
I see now that using V2rayN with This memans that the option works fine and DNS traffic originated from Edge goes through V2rayN. Firefox has its own setup to redirect the DNS request to SOCKS. |
|
well i guess you didn't get the point of @arandomgstring subject. and as i said it's hard to reproduce the problem for us first,and it's harder to get the context of it (took me one week to know what i was looking at) |
Then, it would be nice if you type in Persian and explain again. and you can comment exactly where is the problem. |
well this is were people connect to naive proxy even on android phones, working 1 hour or so normally first time, in a sudden dns things begins, see its the same problem we had, some people are just 1 minute(maybe seconds afterward read his writings complete plz(after before client hello its random for me dude)) some are 1 hour, that might be depend on processing power talked in this conversation . but so we got to fix the dns(must be anycast) to get it back. in the end it's the same scenario, if you feel confident on X V ray stuff they need to become something like naiveproxy to prevent TLS FP. and after that you will face this problem i guess. nothing is for sure its like to know how heuristic antiviruses detecting files. |
|
@alirezaac
I didn't even check packets, I went straight to https://www.dnsleaktest.com/results.html and https://www.expressvpn.com/dns-leak-test both of them showed 2 Iranian DNS resolver. Can you reproduce this? Express VPN website is more accurate. @free-the-internet Feel free to speak Persian btw, I can understand it but I cannot speak it. However our Chinese brothers won't understand you (Maybe use google translate to write in English and Persian at the same time?) |
|
A NAT rule in windows or linux may work for you? I mean redirection of outgoing packets to lo:53 to proxy:port, just after the proxy is connected. Foe Edge browser: https://learn.microsoft.com/en-us/deployedge/edge-learnmore-cmdline-options-proxy-settings
|
One small question: Do you think that some V2ray Clients on Android, and iOS may not tunnel all DNS to the remote server? For instance, I checked the DNS query check (with ExpressVPN you mentioned) in V2rayNG (the latest Android installed) and the setting of V2rayNG configured to be working on VPN mode and 8.8.8.8 VPN DNS, all the android browser (Chrome) DNS query has been sent to my remote server. Have you ever checked the other apps' behavior with V2rayNG or any other V2ray client? I reckon that maybe one simple solution, other than capturing the android packets via root access, is to enable an interface with promiscuous mode (e.g., in Kali Linux) and connect all devices to your same WIFI to see all the packets in the network and trace them. I have Shadowrocket/Oneclick app on iOS and can also check them. |
See this for windows: https://yogadns.com/docs/interfaces/ Checking Android and V2rayNG is also a must. Please if you have time, test it. |
|
I think the guys writing the proxy2tun/tap tools, need to use WPF (windows packet filter). see this: https://github.com/ValdikSS/openvpn-fix-dns-leak-plugin/blob/master/testfw/testfw/PacketFilter.cpp one that is a plugin for OpenVPN. |
yogadns can't, but simplednscrypt can, cause it needs it as a service for interface yoga is just like two Parallel proxifier. but the problem is they are blocking secure dns, and yogadns is not a good tool to check it, some anycast types are working now but its temp, and you are correct i'm not solving my problem here i did it before, average users and phone clients are in trouble for this, They can not run a dns server. the more your connection behave like a real browser the more you are affected . |
If you use YogaDNS to create rules for your interfaces, and not using it as a DNS server; it should work? Am I correct? I see the problem. |
FYI, The problem remains in Windows, Linux. Iphone not tested yet. |
FYI, I can confirm for latest Android stated in my previous comment. For the case of iOS (Ipad iOS), I can confirm that "Oneclick" uses google plain-text DNS, and "ShadowRocket" tunneled the DNS query to the proxy server and use its DNS. |
|
In my recent experience, vmess's DNS problem is totally fixed somehow or another in recent versions of Xray-core (check v1.6.1). |
Hello everybody, I wanted to introduce our VPNalyzer tool to help you test for DNS leaks and in general understand if the VPN has issues. We test for aspects of service like bandwidth overhead when using a VPN, security and privacy essentials like checking what DNS resolvers are used (and more). Importantly, we also test for misconfigurations and leakages such as IPv6 leaks and data leaks during tunnel failure (i.e., when the tunnel fails, either due to bad connection or an intentionally induced tunnel failure, does the data leak to the user's network/ISP?). Our application is cross-platform and you can download it for Windows, MacOS, and Linux. All installation instructions can be found on our webpage. We conduct our tests by asking the user to test both via the VPN and your regular ISP connection. So, a word of warning: anyone monitoring your internet activity (e.g., ISP, government, employer, VPN provider) will be able to see that you are running the VPNalyzer application. NB: In the final step, if the data upload fails because our storage bucket and analysis is done on GCP, please TURN ON your VPN and try again. We present you some results on the application itself and more results can be found on our website a few minutes after the results are uploaded using the unique link we present to you. Read more about our work and the research paper on this topic. |
@alirezaac |
|
@arandomgstring well i've tested the dns leak, it may raise some other confusions too but i know that the problem is deeper than we think. i need to remove my secure dns setup too, to make sure of the problem. but for now its good that we are aware of problem. @free-the-internet thanks for the solution but any solution for android users? cause windows is not that bad for now to fix problems. android is worst in terms of dns now. @poorp well thanks for sharing stats on the restrictions, from the some twitter users stats i'm getting now, the interruptions are coming back, idk maybe that arvan stuff was real and now they are coming back at it again. the xray is fine for now, but we need to agree on that they have contested the interruptions and for some of those weeks it was success for them. |
As I said, android 10+ is completely safe with v2RayNG. |
|
@free-the-internet
While it was unnecessary to hide IPs of Google's DNS servers I did it anyway. As you can see, even in that mode it leaks DNS. Needless to say, I tested in on Mokhaberat ISP on https://www.dnsleaktest.com/ with extended test.
Windows does not support IPTable rules as far as I am aware; only Linux does. So no easy NAT for Windows (yeah I hate Windows because of it) unless someone modify packets directly with WFP or windivert; and it is extremely hard; if someone goes to that point he might as well write a whole VPN from scratch; note that we are talking about a very low programming on C language. Using SSH tunnel for DNS traffic is actually a good idea, but not with our setup (anything related to v2ray, xray, etc core). Iran ISPs don't like SSH traffic coming from foreign servers for normal users. Even a healthy normal ssh access for running commands on port 22 to foreign servers is blocked on Mokhaberat! So one has to chain 2 ssh servers, one VPS from Iran and one from another country, and tunnel traffic like user -> Iranian VPS - > Non Iranian VPS to make it work. Actually; it is the ultimate solution for everything, and at that point we might as well tunnel the whole traffic with -D command of SSH (we won't need V2ray or any third party application for network packets, SSH will act as a SOCKS5 proxy itself). Iran ISPs can counter this by limiting the amount of SSH traffic for every user or limit its bandwidth; but by doing so they will ruin other things. For example, a user who wishes to backup their file on his personal VPS server, can not do that any longer. Or many web-application developers will struggle. That said, do you think they ultimately care? Haven't they already destroyed many people's life by censoring Instagram, Telegram, etc? So normally I don't suggest people to use SSH traffic for this particular purpose, nevertheless it is a good option. On Android 8+ I can confirm that at very least Browsers don't leak DNS on V2rayNG. I cannot say for other applications for sure since I cannot see their packets. However, I am fairly familiar with Kotlin/Java programming of Android Devices, and It is very easy to modify packets on fly using official google libraries; so I don't worry much about Android Devices leaking DNS. That said, not leaking any DNS is actually a problem in itself and can be easily taken advantage of! You see, from ISPs' point of view, a normal user traffic consist of DNS requests, Https traffic, FTP, etc. Wouldn't it be too suspicious if a user doesn't request any DNS resolution at a certain period of time at all? To make matters even worse, android, macos, iphone and windows are all "noisy", meaning they randomly send data to their providers (e.g Windows sends tons of user's information to Microsoft and even registry and other tricks cannot disable it completely. All installed third party application potentially do DNS lookup sometimes) If you don't believe me, just open WireShark and close all applications on background. You still see random DNS lookup, some of them coming from Windows core itself directly, I presume. Same goes for Google collecting data from android devices, Apple from IPhone. Linux itself is silent (and of-course it should be) but still since normal users tend to install applications on it, those application send DNS requests sometimes. Especially if we install Windows app on linux using Wine or something. They can be silenced ofcourse (with a simple host file) but what I am trying to say is either a user should be inactive completely (no traffic of any kind should be sent to ISP) or their traffic has to be mixture of Https, DNS, and other protocols to look normal. If I were in charge of censorship, perhaps the very first rule of mine would be looking at the volume of traffic used by a user on each protocol. Hopefully I got my point across. Actually I think they have done something like this already, since my partners have told me that their naiveproxy or v2ray proxy servers are getting blocked after a few days when they are accessed by smartphones. Perhaps, because V2rayNG redirects all DNS lookups, even the ones that comes from android core itself, its traffic becomes "special", not in a good way of-course. @alirezaac |
well i just tested and no dns leaks, cause im ok for now, but that 1-2 min SSL HS is still happening, just same time with that retransmissions you mentioned, and there are some dns domain in packets resolved as 10.10.34.35 and going through proxy server(weird AF and that's gonna be monitored in that retransmissions too 👍 ) which i was seeing since xray in v2rayn month ago and now seeing it in naiveproxy in nekoray too. i will look in to this another weird behavior but the problem still is not the leakage i'm saying, its that MITM and the tcp drops(RST) we should look forward to it after the solving leaking dns. |
This is really strange. I've tested heavily, multiple times with Wireshark and online services like https://ipleak.net, I hadn't any leaks.
|
This is what is happening now in Turkmenistan. Nobody is allowed to use more than 3GB(?)! They arrest people who use VPN. |
It depends more on the firewall configuration than on the operating system. Any operating system can respond to unsolicited packets with RST, or nothing—it depends on how the local firewall is configured. I don't know what the default for Android is, or if there even is a default. Some background here: https://nmap.org/book/determining-firewall-rules.html#fw-rules-SYN
If you really care to find out, you can check the responses to the T5, T6, and T7 probes in nmap-os-db.
I would be surprised if a VPN worked this way. The physical network interface and the VPN interface are bound to different IP addresses. If something sends a probe to the physical network interface, the receiver of the probe will not just send the reply over the VPN interface. There could be some subtlety I am missing or some point I don't understand, but I don't think the attack you describe is viable. I will mention, however, that there have been routing vulnerabilities discovered that have to do with ambiguities between VPN IP addresses and physical interface addresses. The one I am thinking of is https://breakpointingbad.com/2020/05/25/Vintage-Protocol-Nonsense.html. But it's not the same as what you described; among other things "the attacker also needs to be on the same local network as the victim." |
|
@wkrp
The thing is, firewall can reject or deny packets sent to closed ports, not the opened ones. Basically a firewall will not even look at opened ports, much less already established connections. If we are already receiving packets on say port 20000 (on local port android device) from proxy server, ISP can do a simple MITM attack to that port, without even considering firewall; not matter what operation system we are talking about. For example ISP can send a forged TLS Server Hello with spoofed IP to that port. VPN client will receive this (just like how it will receive other packets from proxy server), but it has no idea where (which application) to route this packet. So I presume, either that packet will be ignored (most likely), or in the worst case scenario a rejection packet will be sent (if the VPN client route that packet to an application anyway) which ultimately gives away the proxy server IP. Due to the symmetric nature of NAT which is used by android under-hood, my bet is that it will be ignored, but I'd like to do a simple test to confirm this. The problem is, I have no idea how to get opened port of ISP, on which user receives information from. The thing is, when a user opens a local port say A on its system and send information through it, because of commercial grade NAT of ISP, another port B will assigned to user such that a very simplified version of flow of information becomes like this
I am unaware of port B to mimic ISP MITM attack from proxy server. On V2ray access log, I see B = 0 for all connections which honestly makes no sense. In reality B is chosen randomly. I know how to get this remote port B in php REMOTE_PORT flag; but I have no idea how to get this in V2ray. What I am trying to do is as follows: When a user establishes connection to proxy server, proxy server sends forged TLS server hello packets to the user with spoofed IP (as if ISP has done a MITM attack here). The spoofed IP belongs to my second VPS on which I log packets received from port 443. If I see my proxy server IP on logs, that would be a very fatal type of attack which can detect proxies with 100% certainty. If I receive nothing, that would be a relief. As you can see this attack is closely connected to #159 . If people has suggested that idea 10 years ago (CensorSpoofer), and that is indeed possible, then I see no reason as to why this type of attack is impossible. If this type of attack is impossible, then CensorSpoofer is simply something to laugh at; or maybe it would be possible to make it work but that would be very complicated. Edited: I just realized that since my proxy server is behind NGINX I get port zero for all connections; my bad. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
I still do not understand the attack you are describing. But you may have a few misconceptions. You seem to think that port numbers are a global resource, shared between all a host's active connections; but the same port number can be used in simultaneous connections to different IP addresses. Just because the proxy client has an established connection to a proxy server IP address with a source port of 20000, does not mean that it will accept packets with destination address 20000 from other IP addresses. The identifier for a connection is a complete 4-tuple (src IP, src port, dst IP, dst port), not just a single port number. If an attacker sends a packet from an unrelated IP address, and the proxy client sends back any response packet, the response packet will surely go to the attacker's IP address, not the IP address associated with any other ongoing connection. An attacker should not be able to inject a TLS Server Hello into the middle of an established VPN connection—if it can, the VPN is no good. (For one thing, a VPN connection is encrypted, and the attacker does not know what key to use to encrypt any injected contents.) To inject contents into a TCP connection at all, you need to know at least the complete 4-tuple, which means an injecting attacker would have to already know the proxy server's IP address, which was the goal of the attack (if I understand you correctly). |
|
First let me to clarify one thing. The goal of attack is not finding IP of proxy server, ISP is already well aware of proxy server's IP along all other IPs that user is directly connected to them. ISP uses this attack to check if an IP which client is communicating with, is a proxy server, or a normal website. Is it clear now, or should I rephrase it a bit more? Consider a client who is connected to N different IPs, on M ports, directly. ISP injects forged packets to an opened port of client IP, to see how it reply back. Based on client's response, ISP can decide that if one those N IPs is a proxy server's IP or not.
Exactly. To begin with ISP has full access over 4-tuple (src IP, src port, dst IP, dst port) as the middle man, for what it's worth, ISP has to know it, otherwise it can't forward packets between client and proxy, back and forth. In other words, ISP knows IP of android client (source IP), port of android client (source port) And this 4-tuple (src IP, src port, dst IP, dst port) is not encrypted because it exist on IP layer on TCP/IP model. We just encrypt everything above TCP layer (i.e application layer). What ISP doesn't know however, is that if destination IP belongs to a proxy server or a normal website. If ISP found a guilty IP, it can easily block it, so ISP tries to uncover which IPs belong to proxy servers
That's the point! The question is, does VPN agent proxify client's response first? i.e Does attacker receive client's response from proxy server, or from the client directly? How does a global VPN agent decide, whether to proxify a packet or not?! For example, lets say attacker injects a sync packet to client's IP. ISP, as an attacker, can easily do that, and it is doing that as we speak. Now the client wants to send a RST packet to attacker's IP (i.e ISP here). Does VPN agent knows, this response shouldn't be proxified? It doesn't know. So VPN agent encrypt this RST packet, and send it to proxy server. Proxy server will decrypt client response and forward it to attacker's IP. While ISP, as the attacker, expect to receive RST packet from the client himself/herself, ISP will receive RST packet from proxy server! So ISP simply block proxy server, easy peasy. That is it. |
What if you block Iran's IP range in Firewall? https://github.com/cloudcraftteam/Import-firewall-blocklist included the PowerShell script and text file containing entire Iran's IP range. after that, enable Firewall logging for dropped/blocked connections to view the results. You can use this PowerShell script to easily view Firewall logs |
|
@lulMeow Oh, ISP should be a fool to use domestic IPs to use this method, since V2ray users already use direct connection to domestic IPs and they are well aware of it. No, No! ISP uses foreign IPs, that by default, get proxified by VPN agent. And since we are talking about a government, they can have hundreds (in IPv4 range), and millions (in IPv6 range) IPs, so that we will never know which IPs are being used in this method. What pains me more, is that this method is super simple and has efficiently of 100%. The only way to combat this, is to proxify trusted IPs. That's a shame though, because a website such as youtube has literally hundreds of IPs, so proxifying based on IP is not viable. |
But why V2Ray users use direct connection to domestic IPs? for example, I'm in Iran, use VLess/VMess/Trojan etc. to connect to a remote server located in Europe or U.S. I can use plain text Cloudflare DNS servers in the router/modem. now I block entire Iran's IP range in Windows Firewall, and since inbound connections are already blocked by default in Firewall rules (unless there is a specific allow rule), no Iran's IP can connect to my client. So please explain what's wrong with that scenario and if there is any security holes in it. you can harden your client further by
|
|
@arandomgstring rather than worry about an imagined attack, I encourage you to run some of your own experiments to convince yourself whether it is or is not really possible. Here is something to think about. Remove the complication of a VPN and just think about a host with two physical network interfaces: eth0 with address A.A.A.A and eth1 with address B.B.B.B. Suppose a third party sends a SYN to A.A.A.A. How does the host decide whether to send the response RST packet on the eth0 or eth1 interface, and how does it decide what source address to use? It is the same situation with a VPN, except that one of the network interfaces is a virtual interface, not a physical interface. This thread has gotten off track, and its original purpose was not very clear to begin with. I think it's a good time to end the discussion until someone has some concrete observations. If you suspect there is some interaction between DNS queries and TCP blocking, the way to investigate it is to design and run an experiment. State a clear hypothesis: "TCP connections to IP addresses that that have not been returned in a DNS response in the past X seconds will be blocked by RST injection within Y seconds." Design an experiment to try to find evidence against the hypothesis. Run it multiple times at different times of day keep a written table of observations. |
|
@lulMeow
Mostly because of this issue #129 (comment) (I suppose this issue doesn't concern Iran yet, it might affect Iran in future, read @wkrp explanation in that topic too) and more importantly some domestic IPs only allow IPs from inside, not outside. For example you can't open downloadly.ir with a VPN. You need an Iranian IP. To use banks, and other type of domestic services, it's better to use domestic IP, for a better speed at very least. So we split connections to two sides, for domestic IPs we don't use proxy, and we connect them directly, for all other IPs we use proxy. It even "mixes" traffic of client, so the danger of getting proxy server blocked reduces.
Well I am more concerned about Smartphones (android, IPhone), not Windows and Linux; because I have been informed that servers tend to get blocked more often when android devices connect to them. In smartphones, setting up a secure environment is much harder. At any rate, blocking all incoming connections doesn't easily save you from forged packets sent by ISP. When you open an outbound connection to any foreign IP (for example your proxy server) ISP forward packets from proxy server to your device. So ISP can forge and send packet to your device in place of proxy server as the middle man (MITM attack) in that outgoing connection. For example it can send RST packet to abort the connection, as it does now (naiveproxy's users in Iran has been affected by this type of attack, they get RST packet, therefore they cannot do a complete SSL handshake). However, Windows and Linux and MacOS are not that helpless. Some routers maintain a cache, in which destination IPs of user is saved. If any IP (except for what we have in the cache) try to send packet to router, router will ignore it. I am not sure if all routers do this though. When we talk about Smartphone which use their Sim-card to connect to internet, the story is very different. I will check your links, though your third advise "Disabling Multicast DNS" is exactly what I told people to do in this topic. It doesn't address the new problem that I said in this topic though. |
Thanks, I reviewed that post. Remove apps belonging to Iranian companies and banks, totally unsafe. use a computer like Windows to have full control over your incoming and outgoing data as much as possible, IPhone is totally out of the question, but Android can be rooted to give you extra freedom on things you can change. Do NOT download any files, from any Iranian website, whether it's download.ir, soft98.ir etc. they can not be trusted and they could contain malware, always download your programs from official sources. if on Windows, use Winget which checks file hashes automatically. when it comes to your OS, it's even more important to make sure it's from the original source and not some 3rd party website ending with .ir. you can check certificate store of your phone too to make sure there isn't any bad certificates in it, but I'm not sure how Smartphones handle the authenticity of certificates and if one of them goes rouge, how soon the OTA can be issued to revoke them. Like I said, it's an extreme situation, habits should be changed. hopefully the regime will be changed and all this won't be necessary any longer. p.s when I mention Iran, I'm talking about regular Iranians and the terrorist islamic republic together, since they can disguise themselves as normal people or force people to do things on behalf of the regime, so it's a zero-trust situation. |
Drop all incoming SYN packets. This is easy in Linux, maybe also Windows. But I don't know Android or iPhone. |
I just tried a better solution and testing it right now on Windows 11. so based on IPSec policy in Windows, follow this answer: Add your V2Ray/Xray/Proxy's IP Address to the permit list, add your custom DNS (like Cloudflare's) to the permit list, then block all connections from any source and destination IPs. if you want to allow localhost, then there is another solution here: So now if the islamic regime tries to send your client a SYN packet or any kind of packet at all, it will be automatically dropped, no matter if they use Iranian IP or foreign IP address. (I find this method to be more robust than the previous solution I suggested that used Firewall to block entire Iran's IP range) the only connections that are allowed will be Cloudflare's 1.1.1.1,1.0.0.1 and your V2Ray proxy's address. Please do let me know if there is any problem with this approach. |
Well i was doing this with a pie box to act as physical firewall and dns. and my phones mitigated by this but the problem these days are phones and if you read on people simple solutions they keep changing clients on android to randomly solve this. maybe some clients fakedns are mitigating them. and the so called BROOK thing that is getting hype have some strategies for dns maybe thats why its making people more satisfied however i didn't test it yet. |
|
@free-the-internet As @wkrp correctly pointed out, this imaginary attack that I described is completely off topic and they are totally right, so It might be better if we discuss it somewhere else. At any rate, I am planning to conduct this imaginary attack on myself; it takes some time though until I find correct setup. Just to point out a few things, @free-the-internet note that ISPs are not limited to sync packets, they can send any packet they wish. For example they can send a TLS server hello with attacker's IP. VPN agent has no idea if this TLS server hello comes from a normal website seen by user, or attacker's IP. Because it doesn't maintain a cache for this purpose. @lulMeow That's a nice solution. Same can be done on Linux with IPtables rules. That said, what if ISP expect you to send a reply packet and if you don't they automatically ban the foreign not whitelisted IP you have used the most temporarily, and then permanently? @alirezaac Correct. I am telling people, on desktop we are totally free to defend against such attacks. Hell, we can open a wireshark and capture any packet injected to our system, and bust them, easy; on smartphones though ... Anyway I am planning to share internet with my Laptop's Hotspot and connect my android device to it, then I will try to inject packets to my android device, here, my laptop would be first hop of android so I expect it to work. I will be using Scapy for IP spoofing. If I find any success (or failure if you will) I will share it in another post. If you can and have enough time, you might try it yourself. IP and opened port of android device can be seen in Wireshark, with a simple one liner you can inject packets to android, and finally if you install pcap you can see if android has received those injected packets or not. @wkrp |
I don't think they do that, unless there is a proof. ISP can't expect every client to reply back to any request. what protocol do you have in mind that they might use? because first of all, that'd be unsolicited traffic, blocked by Edge Traversal in Firewall, and second, your computer is behind NAT router. so, unless you put your computer in DMZ and turn firewall off, no unsolicited connection should come through. Even Google can't just send a random connection to my computer, only my computer can initiate the connection and then expect a reply, because unsolicited traffic is blocked by default in most rules. Windows Firewall is a stateful firewall, which is better than stateless, and TCP SYN will be blocked from outside if not first initiated by the user. check how many rules aren't blocking Edge Traversal
then set Edge Traversal to block for all of them
I don't think there is anything to worry about if you configure your client properly :) |
Firefox have its internal DNS cache. You can view, clear dns cache in |
Forgive me for opening a new topic regarding this issue, however I think it is worth of a topic of its own. At the beginning, findings of @alirezaac in this topic #153 made no sense to me. But after further investigation I found some very useful information that I like to share. This issue #154 is related too.
Tl;dr: So in a nutshell ISPs expect their users establish connection with IPs that which was requested through plain DNS, if that doesn't happen; TCP connections are severed by RST packets.
As @free-the-internet correctly puts it
Indeed, DNS resolution happens at the very beginning of every domain related connection so what causes blockage of TLS Handshake to proxy server, when IP and domain of proxy server is not blocked? Why DOH alleviates this problem; but it cannot solve it completely? And why TLS fingerprint does not help?
First of all, note that DNS resolution has nothing to do with IP & domain of proxy server itself. Why?! Because from @alirezaac or my images we can clearly see that TCP connection is already established to proxy server. If it were the case of DNS poisoning or something, we couldn't even establish connection to proxy server itself to begin with. Moreover, we can simply add IP & domain of proxy server in host file (or DNS configuration of client proxy) to resolute proxy's domain locally, and believe it or not, it solves nothing which further proves my point.
Secondly, DOH and other types of encrypted DNS resolutions are completely or partly blocked in Iran. I have personally checked Google and Cloudflare DNS DOH servers in YogaDNS and can confirm this on Mokhaberat and Irancell ISPs. Please do share your finding. So DOH in itself is not much of help; unless we somehow get access to it (I will explain more down below).
So inevitably, users are forced to use plain DNS on normal circumstances. Either of ISP's DNS resolver, which gives bogon IPs for blocked servers Vless + TLS has a weird behavior on Iran VPS #154, or plain DNS google & Cloudflare or other configured DNS servers are used. There is a catch with plain DNS requests. ISPs can monitor these plain DNS requests and this is a big problem. According to my investigations (please share your findings regarding this issue), when a user wishes to visit a domain I hypothesis:
ISP matches IP address of requested domain (ISP knows it through plain DNS) with the IP of newly established connections. If they are the same, nothing out of ordinary happens. However, lets assume a scenario where the user requests Youtube.com on their browser through plain DNS. ISP sees that the requested IP is 142.250.185.110 (youtube's ip); however user sends no sync packet to 142.250.185.110 at all, rather it continues to take data from another IP (IP of proxy server). It is a very clear sign of using a proxy; when this happens ISP sends RST packets to user and destroys the connection; user tries to reestablish connection to proxy server but ISP sends RST packets to proxy server and we receive no server hello.
Since the network traffic is mixed up, ISP won't block proxy IP at the beginning, because consider this scenario: User download a file from a whitelisted website and at the same time opens a blocked site, the traffic is similar to former case, and if ISP were to block that IP many whitelisted Iranian websites would be affected at the same time. But by utilizing this method they can artificially "pause" a traffic, especially if that traffic comes from other countries.
I personally tested this by downloading Ubuntu ISO (which is whitelisted) on client side and opened a blocked site. The downloading process stopped abruptly in the mid way, and no matter how many times I used download manager to continue the download, I saw the error of "the web-server refuses connection". I pinged the link which I was download from, and it was fine. I used a VPN and successfully continued downloading the file. I assume the fact that web-server was refusing to give me more packets is a clear sign of ISP sending RST packet to Ubuntu server and download manager not receiving server hello under hood. Caching all user DNS requests is wasteful and costful on ISP part, so after a certain timeout (maybe a few seconds), when no sync packet is sent by user to the requested IP address of a certain domain, they destroy TCP connections and forget previous DNS requests. Another thing that which probably further proves my point, is the fact 2 years ago, when all VPNs stopped working a VPN called "Your Freedom VPN Client" could work on DNS mode, presumably using private DNS resolver for IPs.
Solution: I might be very wrong about the whole procedure of blockage, after all it's all but guesswork. That said, it's very clear that when DNS requests are encrypted we face not such problems. But again we return to the very first problem, DOH is blocked, at least for well known servers.
Client potentially put all correct IP addresses and domains of their favorite websites on host file so that DNS resolution happens locally. The problem is not all applications respect host file and I know no way of forcing apps to use host file. Let me know if there is any. It seems to me that browsers randomly use host file sometime and some times not.
Using DOH of not very well known web-servers might be a temporary solution, but they will eventually be blocked.
Perhaps running DNSencrypt server on proxy server would be optimal solution. I haven't done this yet, let me know if anyone has done this and what results were.
The text was updated successfully, but these errors were encountered: