web-dev-qa-db-ja.com

私のマシンからのUDPフラッド、または誤検知?

私の専用サーバーをホストしている会社から、私のマシンからの悪意のあるトラフィックであると彼らが考えるものについて警告を受けました。彼らは、私のマシンとネットワーク上の別のマシンのIPアドレスからの大量のUDPトラフィックを示すグラフを提供しました。どちらもロシアのWebホストのように見えるアドレスに向けられています。トラフィックは約15分間続き、約80 Mbpsであり、私が町を出て、サーバーにログインしていないか、サーバーで特別なことをしていない日に発生しました。私のマシンはdebianを実行しています。私のウェブホストは、「ヌルルートを削除したため、再び開始されないようです」と述べています。 (それが何を意味するのか分かりません。)私はrkhunterと呼ばれるルートキット検出器を実行しましたが、何も表示されませんでした。

私はセキュリティに関する高度な知識を持っていないので、これが私のマシンが侵害された強力な証拠であるかどうかを評価することは困難です。 この答え で次のことに気付きました:

サーバーがパケットの送信元であると確信していますか? UDPパケットのソースアドレスを偽造するのは簡単です。

私のWebホストからの情報は、マシンが危険にさらされており、再インストールを行わせる必要があるという強力な証拠ですか?

[編集]これはおそらく、ポートマッパーサービスが、UDPを使用するポートマッパー増幅攻撃と呼ばれるものに対して脆弱であるためであると後で知りました。私はNFSを使用していないので、 このサービスをオフにする を使用できます。

7
Ben Crowell

ホスティングプロバイダーからレポートを受け取りました。トラフィックがサーバーから発信されたものか、それともスプーフィングされたものかを知ることができます。したがって、ホスティングプロバイダーが有能である場合、レポートはおそらく正しいです。

私があなたの立場にあったなら、私がすることは2つあります。ホスティングプロバイダーに、フラッドトラフィックのサンプルのパケットキャプチャを送信できるかどうか尋ねます。パケットトレースを検査した後、レポートの正確さを判断するのにより適した状態になります。さらに、サーバーにログインしてifconfigを実行し、マシンが最後に再起動してから送信されたトラフィックの量を確認します。 (32ビットシステムの場合、カウンターは4GBでラップアラウンドするため、正確であるとは限りません。)

ホストがUDPパケットのフラッドを送信した場合、それが発生した可能性があるさまざまな方法があります。しかし、最もありそうな説明はある種の妥協です。ルートアカウントを危険にさらすことは、UDPパケットのフラッドを開始するために必要ではなく、単一のアカウントを危険にさらすことで起こります。ソケットがまだフラッドトラフィックの送信元ポートにバインドされているかどうかを確認できます。運が良ければ、そのプログラムがそのトラフィックを発生させていることに気付くでしょう。正当なプログラムが何の妥協もせずに誤ってパケットのフラッドを誤って生成するのを見たことがあります。 UDPを介して通信する内部開発のソフトウェアがある場合、これはあなたに起こった可能性があります。

プロバイダーに表示するパケットトレースがなく、ネットワークインターフェイスのバイト数が大量のデータが送信されたことを示していないことが判明した場合、システムの侵害の証拠を見つけることができません。 、それからプロバイダは、独自の調査を実行せずに、受け取った偽のレポートを単に転送しただけの可能性があります。

7
kasperd

セキュリティに関する高度な知識がありません

それがここの問題です。

アウトバウンドフィルタリングiptables/packetfilter(vulgo:ファイアウォール)がインストールされていますか?

私のWebホストからの情報は、マシンが危険にさらされており、再インストールを行わせる必要があるという強力な証拠ですか?

おそらく:はい(再インストール)。サーバーは悪用されたと見なす必要があります。

しかし、単純な再インストールでは、最初のエクスプロイトの根本原因を排除することはできません(webapp?不正なパスワード+総当たり?誰が知っているのか...)