web-dev-qa-db-ja.com

DOSおよびIPの変更後のダウンタイムの回避

私は小さな会社でWebサイトの設計、プログラミング、保守を行っています。共有ホスティングプラン（cpanel）でWebサイトをホストしています。 2日前に、DOS攻撃とプロバイダーIPアドレスの変更があったというメールを受け取りました。その後、ネームサーバーIPを変更し、DNSの伝播を待つ必要がありました。これには、クライアントがメールやWebサイトにアクセスできなかった2営業日ほどかかりました。また、ダウンタイムは短期的にはWebサイトに影響を与えます（ランキングなど）。ですから、クライアントが猛烈に私に電話している間、私は座って何もできずに待つことができました（私は彼らを責めません）。

だから私の質問は：

  • DOS攻撃が発生したときに、ホスティング会社がIPを変更するのは適切な対応ですか？同様の機会にサーバーをシャットダウンしていた会社から切り替えました（！）
  • この出来事から自分を守るために私は何ができますか。小さな会社でしたが、今まで私は素晴らしい評価を受けていました。これが二度と起こらないようにしたい。

ポリシーがDOS攻撃でIPを変更することである場合、専用サーバーに移動しても何も変わりません。私が見つけた別のオプションは、すべてのサイトを2番目のサーバーにミラーリングする必要があるフェールオーバーDNS（2倍のコスト）です。他の選択肢はありますか？

shared-hostingdns-serversbotattackdowntime
3
electrique

帯域幅が限られている（1〜10 Gbps未満）中小企業の場合、IPアドレスプールを変更するのが最適で、安価で迅速なオプションです。

キャリア、CDNプロバイダー、または大企業のみが、他のソリューションでDoS攻撃を軽減できます（帯域幅は彼らにとって問題ではありません）。

DNS伝播については、whoisレジスタは非常に長い時間を要するものであり、DNSエントリは迅速に変更され、TTLの有効期限が切れるとすぐに伝播する可能性があります。

これは、TTLキャッシュに関する例です。

redstar@nvidiastar:~$ Dig +nocmd +noall +answer www.google.com
www.google.com.     72  IN  A   216.58.201.132
redstar@nvidiastar:~$ Dig +nocmd +noall +answer www.google.com @216.239.32.10
www.google.com.     300 IN  A   74.125.206.147
www.google.com.     300 IN  A   74.125.206.104
www.google.com.     300 IN  A   74.125.206.103
www.google.com.     300 IN  A   74.125.206.99
www.google.com.     300 IN  A   74.125.206.106
www.google.com.     300 IN  A   74.125.206.105

DNS解決を探すとき、ISP DNSはTTLが72秒のIPに応答します。 TTLが何であるかを知るには、そのドメインのDNSサーバーに問い合わせる必要があります（216.239.32.10もその1つです）。 Googleでは、エントリのTTLは300秒であるため、IPを変更でき、伝播時間は最大5分です。

別のネットワークでバックアップDNSサーバーを使用すると、状況が解決します。

使用できる無料のセカンダリDNSプロバイダーがあります。私はTwisted4Lifeを数年間使用していますが、BuddyNSも確認するか、任意の検索エンジンで「無料のセカンダリdns」を検索できます。

また、無料のセカンダリDNSサーバーについては、CloudFlareを無料のDNSサーバーとして使用することも、静的コンテンツをキャッシュする（または、機能を無効にできない）CDNとして使用することもできます。

1
OscarGarcia

DOS攻撃が発生したときに、ホスティング会社がIPを変更するのは適切な対応ですか？同様の機会にサーバーをシャットダウンしていた会社から切り替えました

1、IPアドレスの変更により、ドメイン名TTLの有効期限が切れるまでウェブサイトの準備ができなくなるため、IPアドレスを変更しても利点が得られないことがわかります。 2、深刻なハッカーがインターネット上のすべてのIPをスキャンして、攻撃の標的になりやすいシステムを探します。攻撃に応じて、サーバーをシャットダウンする方が良いかもしれません。

この出来事から自分を守るために私は何ができますか。小さな会社でしたが、今まで私は素晴らしい評価を受けていました。これが二度と起こらないようにしたい。

システムリソースとWebサイトを確認します。

Webサーバーソフトウェアが効率的に実行されていることを確認してください

Webサーバーのタイムアウト設定が高すぎることを確認し、サーバーで実行中のスクリプトが遅れないことを確認します（たとえば、無限ループを含むスクリプトを実行しないでください）。

Apacheでは、スクリプトを処理するために使用できる空きスロットはx個だけです。これらすべてのスロットが使い果たされると、Apacheへの接続はスロットが解放されるまで待つ必要があります。スロットは、タイムアウトが発生した瞬間、または結果の最後のバイト（HTMLページ、画像、または未加工コードなど）が送信された瞬間に解放されます。

Xの値は重要です。設定が低すぎると、特に1人のゲストが数ギガバイトのサイズのファイルをダウンロードする場合、ゲストがページの提供を通常よりも長く待機する可能性があります。要求された各リソースは1つのサーバースロットを使用することに注意してください。典型的なページの場合、これはそれぞれ約200ミリ秒で一度に3つのスロットを使用できることを意味します。 HTML用の1つのスロット、Webサイトアイコン（favicon.ico？）用の1つのスロット、およびページ内の画像用の1つのスロット。

Xの設定が高すぎると、システムが実際のRAMを使い果たすため、スワップメモリ​​（より遅いストレージスペースからのメモリ：ハードドライブ）が必要になるため、DOSのフィーリングがさらに発生する可能性があります。リクエストを処理しようとしています。

ポートの最大化

サーバーが一度に開くことができるポートは非​​常に多くあります。一部のサーバーは、非常に限られた数のポートを開くように構成されています。他のシステムデーモンが使用するポートを重複させずに、範囲を可能な限り増やします。サーバーにWHM/cpanelがあり、ポート範囲を5000〜65535に設定しています。

最も重要

スクリプトに注意を払い、timimgを見てください。

ページを作成したら、webpagetest.orgにアクセスしてURLを実行します。接続速度の下でネイティブ接続設定を選択します。最初のバイトまでの時間がサーバーから最も遠い地点から400ミリ秒を超えており、リモートデバイスがモバイルでない場合は、問題が発生していることがわかります。

また、私が言ったように、サーバー上のすべてのスクリプトを確認してください。それらのいずれも無限ループを実行したり、リソースを独占したりしないようにしてください。また、サーバーオーバーライドファイル（Apacheを使用している場合は.htaccessなど）で悪意のあるものがないか確認してください。

すべてを保護

最後に、すべてを保護します。世界にふさわしくないポートを閉じます（リクエストをドロップします）。 MySQLポートを閉じました（MySQLサーバーに際限なくアクセスしようとしたときに、なぜ顔が赤くなったのかと思った人のために）。

すべてのユーザーがアクセスする必要があるポートは、Webサーバーのポートであるポート80のみです。

必要な場合にのみ、他のポートを開いてください。ハッカーはこれらを標準のバックエンドシェルアクセスポートとして知っているため、ポート22と23は必ず閉じてください。実際、シェルアクセスが必要な場合は、別のポートを使用してください。

0
Mike