「グレート・ファイアウォール」の版間の差分

削除された内容 追加された内容
翻訳告知
英語版から一部翻訳追加
タグ: サイズの大幅な増減
19行目:
このシステムの開発、運用には多くの[[多国籍企業]]が関わっている。[[シスコシステムズ|Cisco(シスコ)]]、[[モトローラ]]、[[オラクル]](当時は[[サン・マイクロシステムズ]])、[[アルカテル]](当時は[[ノーテルネットワークス]])、[[Oath|Oath(オース)]](当時は[[AOL]])、[[マカフィー]](当時は[[ネットワークアソシエイツ]])、[[マイクロソフト]]などの、[[アメリカ国家安全保障局]]と関係の深い[[アメリカ合衆国]]のIT大手企業の名前が挙がっており、実際の[[エシュロン]]など[[シギント]]開発の技術が応用されたとされる。現在は米国内でも問題となっている。
 
==ブロッキング技術==
== 仕組み ==
===概要===
中国国民はインターネットを閲覧する時、ブラウザでURLを入力する時から、ウェブページが表示されるまでの間では、GFWの四重の審査が働いています。
GFWはIPアドレスがルーティングされないことでコンテンツをブロックする。インターネットゲートウェイの標準のファイアウォールとプロキシサーバーで構成されています。
また、特定のサイトがリクエストされたときにDNS偽装を選択的に行うのことができルの上、政府が体系的にインターネット検閲に関与していないように回線故障に見せかけます。
<ref>{{cite news|url=https://www.theguardian.com/china/story/0,,1713317,00.html|title=War of the words |work=The Guardian | location=London | first=Jonathan | last=Watts | date=23 February 2006 | accessdate=31 March 2010}}</ref>
カリフォルニア大学およびニューメキシコ大学の研究者は、禁止されたコンテンツがブロックされずに複数のルーターまたはシステム全体を通過できる場合があるため、検閲システムは本当のファイアウォールではないと述べました。
<ref name="truefire">{{cite web |url= http://www.scienceblog.com/cms/chinas-eye-internet-fraud-14190.html|title= China's 'Eye on the Internet' a Fraud|accessdate=12 September 2007 |author= ScienceBlog.com}}</ref>
検閲に一般的に使用されるいくつかの技術の詳細は以下のとおりです。
<ref>{{cite web|url=http://cyber.law.harvard.edu/filtering/china/appendix-tech.html |title=Empirical Analysis of Internet Filtering in China |publisher=Cyber.law.harvard.edu |accessdate=13 June 2011}}</ref>
 
{| class="wikitable"
=== DNSブロック ===
|-
URLを打ち込むとDNSは対象のIPアドレスを探しに行きますが、このURLがブロック対象になっていた場合DNSは「[[HTTP 404]]エラー(該当するページが見つかりません」と応答を返すので、ユーザーはサイトを開くことができません。<br>
!方法
!説明
|-
|IP 範囲ブロック [[ブラックホール (ネットワーク)|ブラックホール]]
|GFW はある定期的にメンテされる [[IPアドレス|IP 範囲]] リストを保持している、 この範囲にあるIPアドレス宛のトラフィックパケットは発信者に通知することなくそのまま廃棄する ([[ブラックホール (ネットワーク)|ブラックホール]]化)。
 
中国のインターネットプロバイダーによってパケット廃棄の表現は差異が見られますが、
=== 接続フェイズのブロック ===
<ref>{{Cite web|url=https://blog.thousandeyes.com/deconstructing-great-firewall-china/|title=Deconstructing the Great Firewall of China|date=2016-03-08|website=Network Intelligence Blog {{!}} ThousandEyes|language=en-US|access-date=2019-06-01}}</ref>
DNSブロックをくぐり抜けても、監視システムは接続先のIPアドレスをチェックしているので、禁止IPアドレスに入っているものだった時には接続リクエストを中断させられてしまいます。この時ブラウザは「接続がリセットされました。」と表示される。<br>
共通点は、[[MPLS]]ノードを通過するとパケットがドロップされることです。これは、中国の[[インターネットバックボーン|基幹回線網]]で集中的に使用されています。
このブロッグリストは[[Label Distribution Protocol | LDP]]を使用してメンテされる可能性が高いことを示唆しています。
 
このIP範囲ブロッグリストは [https://www.facebook.com/peering/ Facebook] ,[https://ipinfo.io/AS13414 Twitter] and [https://www.dropbox.com/peering Dropbox] [[Autonomous system (Internet)|ASN]]などサイトが含まれている。
=== URLキーワードブロック ===
URLがブラックリストに載っていなくても、検閲対象用語が含まれていた場合にはリクエストはリセットされます。<br>
 
大きくて日々更新するが必要なブロックリストを維持することの複雑さと、[[コンテンツデリバリネットワーク|CDN]]を使用するインターネットサービスには対処しにくいことが証明されているため、通常は最後の手段として使用されます他のブロッキング方法は優先的使用される。 ([[Quality of service | QoS]]に基づくブロッキングなど)。
=== ページスキャン ===
 
リクエストしたURLが開いたとしても、監視システムはそのページを完全スキャンし、見てもOKなものなのかどうかをチェックします。
IPアドレスが封鎖されると、VPNを使う以外回避する手段はほとんどなくなる、その意味では一番レベルが高い封鎖手段でもある、中国にとって余程の都合が悪いサイトに限ると思わています。
検閲対象用語が発見した場合は「このページは表示できません」と表示し、閲覧者はこの後数分または一時間でこのサイトをアクセスできなくなります。<br>
 
|-
| [[DNSスプーフィング]], フィルタリングとリダイレクト
|GFWの一部である詐欺DNSサーバーは [[DNSハイジャック|DNSハイジャック]]で虚偽なIPアドレスを返す<ref>{{cite web|url=http://pcwizardpro.com/how-to-unblock-websites-in-china/|title=how to unblock websites in China |publisher=pcwizardpro.com | accessdate=27 January 2018}}</ref> 。
 
いくつの研究はこのフィルタリングはキーワードに基づくものと示した。<ref>{{Cite web|url=https://www.usenix.org/system/files/conference/foci14/foci14-anonymous.pdf|title=The Great DNS Wall of China - Analysis of the DNS infrastructure|last=|first=|date=|website=|archive-url=|archive-date=|dead-url=|accessdate=2019-06-01}}</ref>
 
検閲システムはおそらく2つのリストを維持している:禁止するドメイン名のブラックリストと、許可するドメイン名のホワイトリスト。 ワイルドカード"<math> * </math>"を使用する可能性もある。
禁止されているWebサイトの例には、「greatfire.org」または「*falungong*」、ホワイトリストに登録されたWebサイトの例には「developer.android.google.cn」がある。
 
キーワードブラックリスト/ホワイトリストは複数の中国インターネットプロバイターで共有しされて、1つところに集約的管理されているように見えます。
 
外国のDNSサーバー ([[Google Public DNS]] / 8.8.8.8 など) は中国国内で正しく機能している
<ref>{{Cite web|url=https://news.ycombinator.com/item?id=16772035|title=8.8.8.8 goes pretty well in the Chinese market. (8 being a popular number.) I th... {{!}} Hacker News|website=news.ycombinator.com|access-date=2019-05-31}}</ref>
<ref>{{Cite web|url=https://www.reddit.com/r/China/comments/5o12ic/dns_servers_in_china/dcg4ty2|title=r/China - DNS servers in China.|website=reddit|language=en|access-date=2019-05-31}}</ref>、しかし、これらのDNSサーバーもハイジャックの対象となります。すべてのDNSリクエストはDNSサーバーに到達しますが、要求が禁止キーワードに一致すると、GFWは偽のDNS応答を入れて、正確なDNSサーバーが応答する前に誤った応答を行います。
 
2015年から、ブラックホールの範囲内でブロックされるドメインへのアクセスリクエストはランダムのIPアドレスが返される
<ref>{{Cite web|url=https://www.solidot.org/story?sid=42606|title=Solidot {{!}} 防火長城使用有效IP投毒DNS,其中包括色情网站IP|website=www.solidot.org|access-date=2019-06-13}}</ref>
 
典型的な回避方法は[[Hosts file]]を修正する、[[Webブラウザ]]でドメイン名の代わりにIPアドレスを入力する、[[DNS over TLS]] / [[DNS over HTTPS | HTTPS]]を使用などがある。
 
|-
|[[プロキシ#透過プロキシ(transparent_proxy)|透過プロキシ]]による[[URL]]フィルタリング
|GFWは、Webトラフィックをフィルタリングする透過プロキシが作動している
これらのプロキシは、リクエストされた[[Uniform Resource Identifier|URI]]、 "Host"ヘッダ、およびWebページのコンテンツ(HTTPリクエストの場合)、または[[Server Name Indication]] HTTPSリクエストの場合)をスキャンしてキーワードを探します。<ref>{{Cite web|url=https://www.eecs.yorku.ca/course_archive/2014-15/W/3482/Team13_presentation.pdf|title=Internet Censorship in China|last=|first=|date=|website=|archive-url=|archive-date=|dead-url=|accessdate=2019-06-01}}</ref>
 
ページがブロックされるべきだとファイアウォールが判断した場合は、代わりに403エラーページが表示されるか、ページがまったく読み込まれない可能性があります。
HTTPリクエストのPOSTデータを検閲できない、不正なHTTPリクエストを検閲できないなど、これらのプロキシに複数の制限があることが調査により判明しています。<ref>{{Cite web|url=http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/12389-foci13-khattak.pdf|title=Towards Illuminating a Censorship Monitor’s Model to Facilitate Evasion, Page 4, section Protocol Message Interpretation|last=|first=|date=|website=|archive-url=|archive-date=|dead-url=|accessdate=2019-06-01}}</ref>
 
また、webSocketのような新しいプロトコルも同様。
DNSフィルタリングと類似、この方法もキーワードに基づいて作動する。
封鎖キーワードはいつも同じではない、2019年では、透過プロキシを使ってwikipedia.orgへのアクセスはブロックされた。
サーバ名表示の暗号化はこのフィルタリング方法をするためにも使用でき、[[Internet Engineering Task Force | IETF]]によって現在開発中です。<ref>{{Cite web|url=https://datatracker.ietf.org/doc/draft-ietf-tls-esni/|title=draft-ietf-tls-esni-03 - Encrypted Server Name Indication for TLS 1.3|website=datatracker.ietf.org|access-date=2019-06-13}}</ref>
 
|-
|[[Quality of service|QoS]] フィルタリング
|
2012年以降、GFWは[[機械学習]]を使用して、トラフィックの特徴に基づいて「学習-フィルタリング-ブロック」することができた。
<ref name="guardvpn2">{{cite news|url=https://www.theguardian.com/technology/2012/dec/14/china-tightens-great-firewall-internet-control|title=China tightens 'Great Firewall' internet control with new technology|last=Arthur|first=Charles|date=14 December 2012|work=guardian.co.uk|accessdate=2013-03-08|publisher=The Guardian|location=London}}</ref>
 
この技術は最初からVPNをブロックするために開発された技術で、すでにGFWのシステムの標準機能の一部になるように拡張されています。
GFWが持つ全部のトラフィック分析用ユニットをミラーリングすることで機能します([[ネットワークタップ]]を使用)。
分析ユニットは、各宛先IP毎に、接続がどれほど疑わしいかを表すスコアに算出しています。
このスコアは、後にGFWのパケット廃棄に使用され、スコアの結果によって、接続が遅くする。
この方法は、トラフィックを極端に遅くし、クライアント側でタイムアウトになることで効果的にブロックすることを目的としています。
 
GFWの分析システムは、[[サイドチャネル攻撃|サイドチャネル]](パケットのサイズなど)を使用して、接続が疑わしいかどうかを推定していると考えられています<ref>{{Cite web|url=http://blog.zorinaq.com/my-experience-with-the-great-firewall-of-china/|title=My Experience With the Great Firewall of China|website=blog.zorinaq.com|language=en|access-date=2019-06-01}}</ref>。
トラフィックパターン(SSHトンネリング、[[VPN]]、[[Tor]]などのプロトコル)を検出し、暗号化されたトラフィック(SSLトンネルを介したHTTPSなど)のパケットの[[情報量]]を測定することができます。
このシステムは機能するために人間の操作を必要とせず、DNSフィルタリングおよびプロキシシステムとは完全に分離されています。
 
|-
| パケット偽造と[[TCPリセット攻撃|TCPリセット攻撃]]
|
GFWは、[[パケット偽装]]を使ってTCP送信を任意に終了させることができます。
ブロッキングはTCPリセット攻撃を使って行う。
この攻撃はTCP要求もTCP応答もブロックしませんが、悪意のあるTCP RSTパケットをリクエスト元に送信し、接続の終わりをシミュレートします。
サイドチャネル分析は、TCPリセットがQoSフィルタリングルータと共存、または共有されている構造から来ているようです<ref>{{Cite web|url=https://www.cl.cam.ac.uk/~rnc1/ignoring.pdf|title=Ignoring TCP RST send by the firewall|last=|first=|date=|website=|archive-url=|archive-date=|dead-url=|access-date=2019-06-01}}</ref>。
 
この構造はスコアリングシステムを更新し、以前のTCP接続がフィルタによってブロックされている場合、両側からの将来の接続試行も短期間(最大数時間)ブロックされる可能性があります。
効率的な回避方法は、ファイアウォールによって送信されたリセットパケットを無視することです<ref>{{cite web|url=http://www.zdnetasia.com/news/security/0,39044215,39372326,00.htm|title=zdnetasia.com|publisher=zdnetasia.com|accessdate=13 June 2011}}</ref>。これを目的としたFreeBSD用のパッチが開発されました<ref>{{Cite web|url=https://www.cl.cam.ac.uk/~rnw24/patches/20060607-tcp-ttl.diff|title=FreeBSD patch - ignore TCP RST|last=|first=|date=|website=|archive-url=|archive-date=|dead-url=|access-date=2019-06-01}}</ref>。
|-
|TLS経由の[[中間者攻撃#政府が行う中間者攻撃|中間者攻撃]]
|
中国のサイバーセキュリティ法にとって、理論的には、中国政府が中国の認証局にルート証明書を要求して使用することを許可しています。
<ref>{{Cite web|url=https://www.dezshira.com/library/legal/cyber-security-law-china-8013.html|title=Cyber-security Law of the People’s Republic of China|website=www.dezshira.com|language=en|access-date=2019-06-01}}</ref>[[CNNIC]]のように、MITM攻撃を仕掛けます。 法律が制定される前の過去10年間にも、複数の事件が発生しました。<br/>
2013年1月26日、GFWによってGitHub SSL証明書が中国の自己署名証明書に置き換えられました
<ref>{{cite web|url=http://news.ycombinator.com/item?id=5124784|title=GitHub SSL replaced by self-signed certificate in China &#124; Hacker News|publisher=News.ycombinator.com|accessdate=2013-06-15}}</ref>。
 
2014年10月20日、中国のiCloud SSL証明書が自己署名証明書に置き換えられました
<ref>{{Cite web|url=https://www.netresec.com/?page=Blog&month=2014-10&post=Chinese-MITM-Attack-on-iCloud|title=Chinese MITM Attack on icloud|last=|first=|date=|website=|archive-url=|archive-date=|dead-url=|accessdate=2019-06-01}}</ref> 。 中国政府がAppleデバイスの脆弱性を発見し、それを悪用していたと考えられています<ref>{{Cite web|url=http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4449|title=Apple CVE exploited by chinese government|last=|first=|date=|website=|archive-url=|archive-date=|dead-url=|accessdate=2019-06-01}}</ref>。
 
2015年3月20日、GoogleはCNNICが作成したエジプトで署名したGoogleの有効な証明書を検出しました。
このことを受けて、そしてより深い調査の後、CNNIC証明書は一部のブラウザで削除されました<ref>{{cite web|url=https://nakedsecurity.sophos.com/2015/04/14/tls-certificate-blunder-revisited-whither-china-internet-network-information-center/|title=TLS certificate blunder revisited ? whither China Internet Network Information Center?|publisher=nakedsecurity.sophos.com|accessdate=2018-10-18}}</ref>。実証された不正がある証明書のみが削除されるので、他の中国の認証局がWebブラウザから削除されたことはなく、その後追加されたものもあります。
<ref>{{Cite web|url=https://bugzilla.mozilla.org/show_bug.cgi?id=1128392|title=1128392 - Add GDCA Root Certificate|website=bugzilla.mozilla.org|language=en|access-date=2019-06-01}}</ref>
 
この種の攻撃は、[[Certificate Transparency]](証明書の透明性)を実装するWebサイトによって回避されることがあります。
 
|-
| [[ネットワーク列挙|ネットワーク列挙]]
| [[ディープ・パケット・インスペクション]](DPI)機能を備えている可能性がある、中国国内の未知のエンティティ、
特に[[TLS]] / [[SSL]]および[[Tor]]のブロッキングを容易にすることために、米国内のコンピュータへの迷惑なTCP / IP接続を開始しました。
<ref>{{cite web | title= Knock Knock Knockin' on Bridges' Doors | first= Tim | last= Wilde | date= 7 January 2012| accessdate=2019-06-01 | publisher= [[Tor Project]] | url= https://blog.torproject.org/blog/knock-knock-knockin-bridges-doors}}</ref>
 
|}
 
閲覧者がブロックされたサイトをアクセスし続ける場合、当局に報告されることもあります。
 
=== ハードウェア構成 ===