すべては12月28日の夜に始まりました。 サポートチャットで2、3のチケットに関する議論が飛び交い、ユーザーがサイトにアクセスできないことに不満を述べました。 IPシステムが攻撃に対する保護を好まないという通知はなかったため、サポートは、ping、トレースなどすべての標準的な診断システムを通じてお客様を案内するように依頼されました。
12月29日の朝、すでに十数件の苦情があり、懸念の種となった。 はい、私自身に何か問題がありました。HTTPSではなくHTTPを介してリソースにアクセスできました。 nginxのログを追跡して、通話に不正行為があったかどうかを確認しようとしましたが、IPに代わって1回も通話が表示されませんでした。
HTTP経由でサイトを開いているときにヘッダーを表示すると、X-Cache：MISS from zapretなどのヘッダーが追加されて、リクエストがプロバイダープロキシサーバーを通過し始めたことがわかりました。 はい、私たちは監督されています。
curlを使用してIPに到達しようとする例
kemko@dell-work: ~ $ curl --insecure --resolve 'testtest.test:443:185.129.101.243' -I https://testtest.test
curl: (7) Failed to connect to testtest.test port 443: Connection refused
kemko@dell-work: ~ $ curl --resolve 'testtest.test:80:185.129.101.243' -I http://testtest.test
HTTP/1.1 404 Not Found
Server: nginx
Date: Fri, 30 Dec 2016 08:09:41 GMT
Content-Type: text/html; charset=utf-8
Status: 404 Not Found
X-UA-Compatible: IE=Edge,chrome=1
Cache-Control: no-cache
Set-Cookie: request_method=GET; path=/
Set-Cookie: first_current_location=%2F; path=/; expires=Sat, 30-Dec-2017 08:09:41 GMT
Set-Cookie: first_referer=; path=/; expires=Sat, 30-Dec-2017 08:09:41 GMT
Set-Cookie: referer=; path=/; expires=Sat, 30-Dec-2017 08:09:41 GMT
Set-Cookie: current_location=%2F; path=/; expires=Sat, 30-Dec-2017 08:09:41 GMT
X-Request-Id: d16e4994ddeae80bec73120545035e75
X-Runtime: 0.025788
X-Cache: MISS from zapret
Via: 1.1 zapret (squid/3.5.19)
Connection: keep-alive
しかし、何のために？ レジストリミラーの1つから新しいダンプダンプを取得し、そこからブロックされたドメインを取り出し、データベースと比較しようとしましたが、一致するものは1つも見つかりませんでした。
それから、私は実際、今は家にいて、自分をブロックする魅力を感じていることを思い出しました。 そして、私はプロバイダーに接続しています。技術サポートでは、かつて働いていましたが、それ以来、いくつかの連絡先が残っています。 運が良かったので、私たちの問題点と必要な支援を明確に説明できた後、プロバイダーの管理者がIPをブロックしたためにドメインを発見しました。
すべての理由はtelzakaz.ruドメインであることが判明しましたが、 レジストリミラーで判断すると193.150.0.212のみがブロックされるため、状況は明確になりませんでした。
このドメインを解決して、すばらしい画像を見てみましょう。
まあ、彼は今、私たちのIPを含めて解決しています。 しかし、Roskomnadzorのアンロードでは、このドメインにはIPアドレスが1つしかなく、それは私たちのものではありません！
以前は明らかに異なるメカニズムを使用していたため、プロバイダーがロックに使用するソフトウェアの種類を尋ねました。 判明したように、今年彼らはZapretServiceからソリューションを導入しました 。 サイトでかなり興味深い段落が発見されました。
dns-requestsによるZapretServiceは、リストされたURLがレジストリにあるサーバーのIPアドレスを計算します
このソフトウェアは、スケジュールよりも早く機能することがわかりました。システムは、アップロードに含まれるすべてのドメインを個別に解決し、受信したIPをテーブルに収集して、正確に機能します。 すべてのプロバイダーが使用するのはこのソフトウェアであり、そのクライアントに対しては利用できなかったという事実からはほど遠い。 しかし、それを使用したのは私のプロバイダーでした。
特にTTKやRunnetでさえ既にそのような動作に気づいていたため、合理的な時間内にすべてのプロバイダーに到達することはないため、ドメイン所有者に私たちのIPを除外するように求める手紙を書き、同時に彼が使用したDNSのホスティングと通信し始めました。
所有者は黙っていました。彼のDNSホスティングは、リクエストに応じてIPのAレコードを削除したくありませんでした（そして、彼はそれを正しく行いましたが、これは私たちにとって簡単ではありません） また、ある時点で、ドメインは14個のAレコードをすべて失いました。 DNSホスティングのサポートはそうではないと言っていたので、明らかに、それは他の誰かのアドレスに対するドメイン所有者の反応でした。 弊社、または残りの13個のIPのいずれかの所有者。
まとめ
あなたのサイトは、大規模な高速道路を含む多数のプロバイダーがいつでも利用できない可能性があります。 このため、禁止されているものをホストする必要さえありません。ブロックされたドメインの所有者が誤ってIPを手に入れれば十分です。
これは多くの質問と考えを提起します。
まず、もちろん、問題が発生します。そのようなソフトウェアのメーカーとプロバイダーは、追加のヒューリスティックに従ってブロックする必要のあるIPのリストを合法的に取得および拡張できますか？ 私は、悔い改めて、法律を徹底的に研究したわけではありませんが、明らかにそうです。 ほとんどの場合、法律は明示的に反対を述べていませんが、再保険のためにそれを行います：明日委員会が来て、あなたがブロックされたサイトを持っているかどうかを確認しようとし、所有者がそのIPを変更したために取得して開きますが、Roskomnadzorはまだアドレスを更新できていませんリスト内。 しかし、私たちは皆、考えられる理由を理解しており、監査人に連絡するのは非常に困難であるため、法廷で彼らの発見に異議を申し立てる必要があります。
第二に、法律でプロバイダーが許可されている場合、法律を変更する必要があります。 ドメインやIPがレジストリにあるかどうかではなく、配信がまだ禁止されている情報がまだレジストリにあるかどうかが重要だからです。 つまり、裁判所はブロックの理由を正確に述べる必要があり、Roskomnadzorは、ブロックされた次のIPサイトのリストを入力する前に、ブロックを引き起こしたコンテンツがまだあるかどうかを確認する必要があります。
しかし、第三に-この明るい未来が来るまで-次に何をすべきか？ ブロックされたドメインを持つ人の好意がなければ、何もできません。
私たちは現在、以下を行うために、実際のアンロードを定期的に受け取るモンスターを作成する必要があると判断しました。
- ブロックされたドメインをエンジン上のサイトに接続することを許可しないでください。
- ブロックされたドメインを解決し、それらのいずれかがIPを返し始めたかどうかを確認します。
- 念のため、ブロックされたドメインへのアクセスを検索してnginxログを解析することもできます（気にしないでください！）。
そして、このモンスターは、問題の存在とその原因について、より迅速に見つけるためだけに役立ちます。 そして、奇跡に頼らずにそれを修正する方法の問題は未解決のままです。