How to distinguish the different artificial network faults in the domestic Internet environment

Add by Zhj: Learning, the original GFW available means so much ah, of course, I guess the real means should be more than this. And GFW are constantly escalating.

Author Twitter: @davidsky2012 Posting to Moonlight blog post http://www.williamlong.info/archives/2195.html

As we all know, in the domestic Internet will encounter a variety of different human network failures, so that we can not access many sites. However, because many people are not familiar with the network, many times will be unable to distinguish between different network failures, resulting in a network failure, it is considered a server failure, or is clearly a server failure, but it is considered a network failure situation. I think it is necessary to explain the characteristics of different network faults and how to differentiate them and solve them.

In the domestic Internet environment, we often encounter network failures are: DNS hijacking, DNS pollution, IP blocking, server firewall IP filtering, server downtime, keyword-based TCP connection reset, stateless TCP connection reset, SSL certificate filtering, SSL hijacking, HTTP session hijacking and other network failures. Here I will explain in turn:

　　1. DNS Hijacking

DNS hijacking can cause us to visit some non-existent or unstable sites, access to the telecommunications 114 search (see the Moonlight Blog "internet browser hijacked after the Internet") or visit Google but show Baidu's homepage (See Moonlight Blog " Google Blog search turned into Baidu ").

If you need to confirm that you are in a DNS hijacking environment, we can use the Windows Nslookup Network Diagnostics Tool in Windows command-line cmd to find a non-existent or unstable domain name for Network Diagnostics:

C:\>nslookup www.SomeRandomDomainName.com

server:ns-pd.online.sh.cn

address:202.96.209.133

Non-authoritative Answer:

Name:www.SomeRandomDomainName.com

address:218.83.175.155

We see that www.SomeRandomDomainName.com should be a non-existent domain name, the DNS server should tell us that the domain name does not exist, but we see To the DNS server to tell us that the domain name of the IP for 218.83.175.155 (114 different regions of the IP are different, the possible IP is not 218.83.175.155, but the region of their own 114 Search server IP address), This IP is 114 search IP, causing us to visit this website in the browser is 114 search page.

If you need to solve the problem of DNS hijacking, you can transfer your own domain name resolution server to foreign countries, such as OpenDNS (see Moonlight Blog "Use OpenDNS to resolve DNS domain name hijacking") or Google DNS (see Moonlight Blog "Google launches free DNS service").

After the fix we use Nslookup to find this site again:

C:\>nslookup www.SomeRandomDomainName.com

Server:google-public-dns-a.google.com

address:8.8.8.8

Google-public-dns-a.google.com can ' t find www.SomeRandomDomainName.com:Non-existent domain

We see the DNS server correctly told us that the domain name does not exist, we will not be hijacked to 114 search.

However, as stated in the last paragraph of using OpenDNS to resolve DNS domain name hijacking, "However, the use of OpenDNS does not solve the problem with the hijacking of DNS pollution." So next, I'll introduce DNS pollution.

　　2. DNS pollution

Because DNS hijacking can solve the problem by changing the domain name resolution server to a foreign country, GFW needs to use DNS pollution to block some domain names. This way, even if you use a foreign domain name server can not get the correct IP server, so you can not access these servers. For example, now the famous microblog ancestor Twitter homepage has been polluted by DNS.

If you need to confirm that the domain name has been DNS pollution and not other failures, first of all to understand that the DNS hijacking is done by the domestic domain name server, so we can replace the domain name server abroad to solve the problem, and DNS pollution is done by GFW, so even if the name server replaced, GFW can still send forged domain name resolution results to replace the correct parsing results. So we can diagnose whether DNS hijacking or DNS pollution is done by using a non-existent foreign IP as our domain name server. We still use Nslookup for Network Diagnostics, select a non-existent foreign IP of 144.223.234.234:

C:\>nslookup twitter.com 144.223.234.234

DNS Request timed out.

Timeout was 2 seconds.

Can ' t find server name for address 144.223.234.234:timed out

Server:unknown

address:144.223.234.234

Name:twitter.com

address:93.46.8.89

We see that since 144.223.234.234 does not exist, there should be no return. But we got a wrong ip:93.46.8.89. Let's test the case of the IP that was hijacked by DNS just now:

C:\>nslookup www.SomeRandomDomainName.com 144.223.234.234

DNS Request timed out.

Timeout was 2 seconds.

Can ' t find server name for address 144.223.234.234:timed out

Server:unknown

address:144.223.234.234

DNS Request timed out.

Timeout was 2 seconds.

DNS Request timed out.

Timeout was 2 seconds.

Request to UnKnown Timed-out

We see that www.SomeRandomDomainName.com does not return results, so it is not contaminated by DNS.

If DNS pollution is to be resolved, we can only use a variety of cryptographic proxies for remote DNS resolution, VPN, or exploit GFW vulnerabilities.

　　3. IP Blocking

IP blockade here refers to the domestic IP of foreign servers joined the GFW blacklist, resulting in most areas and even the country can not directly access the server. Since GFW is distributed, it is possible that some areas can be accessed and inaccessible in some areas. For example, today's well-known cloud storage services Dropbox's home page, is an IP blockade.

First we set the domain name server as a foreign country, excluding the problem of DNS hijacking. We then diagnose if Dropbox's domain name has been contaminated with DNS:

C:\>nslookup www.dropbox.com 144.223.234.234

DNS Request timed out.

Timeout was 2 seconds.

Can ' t find server name for address 144.223.234.234:timed out

Server:unknown

address:144.223.234.234

DNS Request timed out.

Timeout was 2 seconds.

DNS Request timed out.

Timeout was 2 seconds.

Request to UnKnown Timed-out

Apparently, there is no DNS pollution. Then we can do it in a network environment where the ICMP protocol is not filtered (some cell broadband and some of the company's internal networks filter the ICMP protocol and cannot use tracert). We can use the Windows-brought network diagnostic tool in Windows command-line cmd tracert to make a network diagnosis that the Web site has been blocked by an IP or other failure:

C:\>tracert-d www.dropbox.com

Tracing route to www.dropbox.com [174.36.30.70]

Over a maximum of hops:

1 ms in MS 58.35.240.1

2 ms Ms 58.35.240.1

3 MS in MS 124.74.20.45

4 ms (ms) MS 124.74.209.137

5 ms Ms 61.152.86.58

6 * * * Request timed out.

7 * * * Request timed out.

8 * * * Request timed out.

......

We saw that the last IP was 61.152.86.58 (different IP in various regions), then it was out of order, and apparently there was an IP blockade near 61.152.86.58. So let's open ip138 and find out who's in charge of 61.152.86.58:

The ip:61.152.86.58 you queried

* Main data of this station: Shanghai Telecom

* Reference Data one: Shanghai Telecom

* Reference Data II: Shanghai Telecom

Obviously, the problem is here in Shanghai Telecom (other regions may be local telecom in the region), not the Dropbox server.

　　4. Server firewall IP filtering and server downtime

Put these two points together because the external performance of the two cases is the same. But there is a big difference from IP blocking. The last IP blocking IP is Chinese, while server firewall IP filtering and server downtime the last IP is foreign. For example, we take 75.101.142.137 to do experiments, previously deployed Alexa Web site, now this IP temporarily no server (can be viewed as server outage):

C:\>tracert-d 75.101.142.237

Tracing route to 75.101.142.237 over a maximum of hops

1 ms in MS 58.35.240.1

2 ms, Ms 58.35.240.1

3 ms Ms 124.74.37.9

4 Ms 124.74.209.129 ms

5 MS in MS Ms 61.152.86.142

6 ms Ms 202.97.35.154

7 MS in MS Ms 202.97.34.126

8 194 ms 195 ms 194 ms 202.97.51.138

9 171 ms 173 Ms 202.97.50.54

Ten 215 ms 179 ms 175 MS 63.146.27.133

One 279 Ms 280 ms 278 ms 67.14.36.6

* * * Request timed out.

249 Ms 249 ms 244 MS 72.21.199.40

254 Ms 254 ms 254 MS 72.21.222.157

Ms 249 Ms 216.182.232.53

Ms 273 Ms 216.182.224.22

272 MS 269 ms 289 ms 75.101.160.35

* * * Request timed out.

* * * Request timed out.

* * * Request timed out.

We see the last one up to 75.101.160.35, and then we'll find out who this IP is:

The ip:75.101.160.35 you queried

* Main data of this station: USA

* Reference data one: USA

* Reference data two: Washington King County Seattle Amazon Inc.

Obviously, this is a server failure.

If IP blocking is to be resolved, we can only access these sites by encrypting proxies, VPNs, or exploiting gfw vulnerabilities.

　　5. Keyword-based TCP connection reset

Domestic GFW in the HTTP protocol when people visit foreign sites will record all the content, once there are some more "sensitive" keyword, will be forced to disconnect the TCP connection, record the two sides of the IP and retained for a period of time (about 1 minutes), our browser will show "connection is reset." After this period of time (about 1 minutes), because we and the server's IP was GFW record, we will not be able to visit the site again. We have to stop visiting this website and once again visit the Web page without these keywords, then we can visit this website again.

Because of these features, it is also easier to determine whether a keyword-based TCP connection reset is being made. If the browser displays "connection is reset" and cannot access the site again for a period of time, then after this time to visit the Web site without these keywords and access to the page, we are a keyword-based TCP connection reset failure.

Because the HTTP protocol is transmitted in plaintext, the TCP connection can be reset based on the keyword. Therefore, if the website supports HTTPS encrypted access, we can access the website via HTTPS to resolve this problem. However, if the website does not support HTTPS access, we can only access it by encrypting the Proxy, VPN, or exploiting the GFW vulnerability. And the domestic GFW to deal with HTTPS is not no other means. In addition to IP blocking, there are stateless TCP connection resets, SSL certificate filtering, SSL hijacking and other means, followed by the following.

　　6. Non-stateful TCP connection Reset

Since HTTPS is the protocol that encrypts the transmitted data, GFW cannot know what is being transmitted over the HTTPS protocol, but it does not allow people to use HTTPS to access "harmful information", so GFW just monitors (GFW only knows the HTTPS protocol that accesses the site, Does not know what is transferred in it) access to the HTTPS protocol for the specified Web site (such as HTTPS access for Google Docs) will force the TCP connection to be disconnected. In this way, the HTTPS protocol of these sites is not directly used in the country, many people are forced to use the HTTP protocol, so that all the content transmitted by GFW Records.

The result of a stateless TCP connection reset is that the browser displays "connection is reset", except that any page accessed on the server will be reset. If you want to solve this problem, you can only rely on the encryption agent, VPN or exploit GFW's vulnerability.

　　7. SSL Certificate filtering

As with stateless TCP connection resets, because HTTPS is the protocol that encrypts the transmitted data, GFW cannot know what is being transmitted over the HTTPS protocol, but does not allow people to use HTTPS to access "harmful information", except for domain name pollution and stateless TCP connection resets to prevent the content from being censored. There are also auditing methods for SSL certificate filtering. Because the SSL certificate is transmitted in clear text during HTTPS transmission, it is possible to monitor whether the SSL certificate is sent to the specified domain name. If this is the case, then force the TCP connection to be disconnected and the browser will show "Connection reset". SSL certificate filtering occurs only when you use HTTPS to access a Web site.

SSL certificate filtering is relatively rare. If you need to solve this problem, you can only rely on the encryption agent, VPN, or exploit GFW vulnerabilities.

　　8. SSL Hijacking

Disconnecting HTTPS connections prevents people from accessing "harmful information," but does not know what harmful information is being accessed. Based on this, the vulnerability to HTTPS (which trusts all certification authority CAs), CNNIC requests to become a top-level certification authority (Root CA), so that false certificates can be issued in man-in-the-middle attacks to crack the content of HTTPS transmissions. See the Moonlight blog, "Crack Google Gmail's new idea of HTTPS."

It is hard to see if SSL hijacking is being made. When we visit the foreign website through HTTPS, we must check whether the certificate is issued by the National Certification Authority. If issued for a certification authority in the country, it is likely that SSL hijacking will occur and that continued access must be stopped immediately.

If we want to resolve SSL hijacking, we can go to the browser to prohibit domestic certification authorities such as CNNIC (such as "CNNIC, I do not trust you"). But this does not solve the problem completely, if one day an unknown domestic certification authority to participate in the SSL hijacking is difficult to find. Ultimately we also need to rely on cryptographic proxies or VPNs.

　　9. HTTP Session Hijacking

HTTP session hijacking is the modification of normal HTTP return results, in which ads can be added, even a virus Trojan. And the general Internet is hijacked by HTTP session to join ads, it is likely that the site's own ads. HTTP session hijacking can be done because the HTTP protocol is transmitted in plaintext. The Moonlight Blog, "Carrier-class network pop-up ads", "get the evidence of the malicious pop ads of telecommunications" and "who control our browser?" Also has a detailed description of HTTP session hijacking. HTTP session hijacking is usually implemented by ISPs for push advertising, but does not preclude the use of this method in the future by GFW.

To solve the HTTP session hijacking, Moonlight Blog also provides a solution to the idea-"the method of releasing ADSL pop-up ads." Using a browser plugin to block ads can solve some of the problems and not solve them completely. If you want to solve HTTP session hijacking from the technical means, one way is to use the encryption agent and VPN access to all sites, including domestic, but also does not completely solve the problem, if the HTTP session hijacking is set on the router near the server, this method can not be resolved Alternatively, for different HTTP session hijacking, we can then hijack it by swiping the router firmware (DD-WRT and tomato router firmware support customization, may be able to hijack the HTTP session back to the original data), or for different HTTP session hijacking, Use a different local application-tier proxy server for AD filtering.

In the domestic common human network failures are introduced, students can distinguish between different faults and to solve it?

Source: Reader contributions. Author Twitter: @davidsky2012, author Google reader:https://www.google.com/reader/shared/lehui99

How to distinguish the different artificial network faults in the domestic Internet environment (turn)