特定のWebサイトへのHTTPSアクセスをブロックするNetfilterのFILTERテーブルにはいくつかの規則があります。
-A FORWARD -s 10.255.255.0/26 -p tcp -m tcp --dport 443 -m string --string "facebook.com" --algo bm -j DROP
-A FORWARD -s 10.255.255.0/26 -p tcp -m tcp --dport 443 -m string --string "instagram.com" --algo bm -j DROP
-A FORWARD -s 10.255.255.0/26 -p tcp -m tcp --dport 443 -m string --string "snapchat.com" --algo bm -j DROP
-A FORWARD -s 10.255.255.0/26 -p tcp -m tcp --dport 443 -m string --string "tumblr.com" --algo bm -j DROP
-A FORWARD -s 10.255.255.0/26 -p tcp -m tcp --dport 443 -m string --string "twitter.com" --algo bm -j DROP
-A FORWARD -s 10.255.255.0/26 -p tcp -m tcp --dport 443 -m string --string "youtube.com" --algo bm -j DROP
youtube.comGoogle Chromeでリクエストしたときに機能しない最後のルール（YouTube）を除いて、すべてのルールはうまく機能します。 Mozilla FirefoxやMicrosoft Edgeなどの他のWebブラウザを試してみましたが、ルールはこれらのWebブラウザで完全に機能しました。
私はヘッダー、パケット、Webサーバーからの正確な情報に関するHTTP / HTTPSプロトコルの専門家ではありませんが、YouTubeサーバーがGoogle Chromeユーザーのリクエスト（SYN-ACK）に応答したときにエージェント（パケットの添付情報）に「youtube.com」に文字列は含まれていません。この場合、Google Chrome（YouTube + Google製品）のパフォーマンスを向上させるために他の修正がある可能性があります。
bm（Boyer-Moore）から（Knuth-Pratt-Morris）にアルゴリズムを変更してみましたが、うまくいきませkmpんでした。
私の質問は次のとおりです
- お持ちですか？IPテーブルIPをブロックせずにChrome経由で「youtube」へのリクエストをブロックするルールは何ですか？
ベストアンサー1
これらの意見を見ると、netfilterがそのタスクに間違ったツールであることに気づくようです。
ここで何が起こっているのでしょうか？
Google ChromeはTLSサーバー名表示（SNI）拡張を使用していないため、送信するパケットの中に暗号化されていない宛先ホストの名前が含まれておらず、ユーザーが指定したルールと一致するパケットがなく、ルーターはあなた以外の暗号化トラフィックを読むことができません。これをトランスペアレントプロキシに設定し、それを介して行われたすべてのHTTPS接続に対して中間者攻撃を実行します。
TLS SNI は、HTTPS 接続の暗号化に使用される一般的な TLS プロトコルの拡張であり、システムが接続を試みるホストを指定するために使用されます。特に、TLSハンドシェイクのこの部分は暗号化されていない状態で送信されます。接続の暗号化に使用されるTLS証明書の選択は、クライアントがアクセスしようとしているホストによって異なります。表面的には、同じIPアドレスで何百または数千のホスト名を提供できるWebホスティングサイトを考えるまで、これらすべては無意味に聞こえます。
HTTPは実際にはこの目的のために要求ヘッダーも指定しますが（少なくともバージョン1.1および2.0では）TLSハンドシェイクが完了した後にこのヘッダーが送信されるため、接続に使用されるTLS証明書を決定するために使用することはできません。これは、ホストされているすべてのサイトが同じドメインにあり、接続がそのドメインのワイルドカード証明書を使用している場合にのみ使用できるオプションです。
実用的な観点から見ると、TLS SNI は通常必要ありません。これは、人々が定期的に訪問するほとんどのウェブサイト（ブロックしようとしているウェブサイトを含む）が個別にホストされているか、HTTPヘッダーとワイルドカード証明書を使用するためです。実際、一部のウェブサイトはそうではありません。これをまったくサポートしないでください（クライアントがそれを使用しようとすると、ハンドシェイクが失敗する可能性があります）。また、TLS SNI は、ユーザーがどのサービスにアクセスしようとしているのかを確認することは容易ではないため、ユーザーがローカルで DNS 情報を取得した場合に情報を漏洩する可能性があります。
したがって、Google Chrome（およびChromiumおよび他のほとんどの派生製品）は最初にSNIを使用せずに接続しようとし（ほとんどの人に機能します）、その後SNIを使用して失敗します。他のほとんどのブラウザは最初にSNIに接続し、失敗した場合にSNIなしで試すより自由な（安全性がなく、検閲しやすい）アプローチをとります（ほとんどの人は通常そうではありません）。
問題を解決するための最良の方法は何ですか？
まず、やらないことを検討してください。これらのポリシーを厳密に実施する試みは、明示的に承認されたサービスのみを許可するかなり厳しいレベルに達しない限り（明示的に許可されていないサービスをブロックするのではなく）、非生産的で機能的に不可能です。なぜなら、人々はまだVPN接続またはプロキシを使用してアクセスできるからです。 （すべてのVPNとプロキシ方法をブロックすることはできません）。
実際にこれを停止する必要があると明示的に主張する場合は、UDPポート53で一致するようにルールを変更してください。これにより、ドメイン内のカプセル化されていないDNSトラフィックがルーターを通過するのを防ぐことができます（注：はいDNSトラフィックは暗号化され難読化され、深いパケットチェックを実行し、他の多くをブロックしないと簡単に何もできません。ルールが対称であることを確認してください（つまり、アウトバウンドトラフィックだけでなくインバウンドトラフィックもブロックします）。これにより、この種の問題に対するいくつかの回避策が正しく機能しなくなります。