web-dev-qa-db-ja.com

多数のログイン試行の失敗-cPanelHulk Brute Force

Mods:この質問は特にサーバーに関するものであることに注意してくださいcPanelとWHMを介して管理されているため、 重複した質問の疑いとは異なります。

先月、私の個人用Webサーバーはこれらの通知を何千も受け取りました。私のサーバーは主にWHM/cPanelによって管理されていますが、ルートssh、ftp、その他の従来のアクセスポイントがあることに注意してください。

これらの攻撃はrootを試みることから始まりましたが、その後、ユーザーアカウントの試行に進み、正しいユーザー名をどのように推測したかさえわかりません(パスワードは間違っていますが)。

このような攻撃を防ぐ方法はありますか?

また、今日リストされている自動禁止の数とIPアドレスソースの一部があります-過去1か月の攻撃時間は、基本的に東海岸の午前6時30分から午後11時頃です。

enter image description here

2
ina

あなたはこれを言います:

先月、私の個人用Webサーバーはこれらの通知を何千も受け取りました。

慌てる必要はありません!システムのrootアカウントを無効にするだけです。

現代のインターネットへようこそ!これらの通知を個人的に受け取らないでください。また、Webサーバーに対する標的型攻撃の兆候としてこれらの通知を受け取らないでください。むしろ、これは何らかの方法でオンラインに存在するWebサーバーの正常な部分です。ボットネットの軍隊は常にWebサーバーをスキャンして弱点を探し、時々さまざまな理由でそれらの弱点を悪用します/ハック。

懸念がある場合、この状況を解決するためにできる最善の、最も簡単で簡単なことは、サーバー上のrootユーザーを無効にしてから、システム上の別のユーザーにSudo権限を割り当てることです。それを行うだけで、追加のソフトウェアをインストールすることなく問題を解決できます。

はい、サーバーに Fail2ban のようなソフトウェアをインストールすることを推奨する人もいます。これはオンライン防衛兵器の悪いツールではないと思いますが、次の場合は誤った安心感を与える可能性があります。システムでrootユーザーアカウントを無効にするほど基本的なことはしていません。

システムでこれを行う最も簡単な方法は、最初にSudo以外のシステム上の他のユーザーにroot権限を割り当てることです。それが完了したら、SSH経由でそのユーザーとしてログインし、次のコマンドを実行します。

Sudo passwd -l root

これにより、rootユーザーのアカウントが効果的にロックされます。したがって、これらのボットにrootを介して今から永遠にログインを試みさせてください…rootを無効にすると、その努力は無駄になります。

そうは言っても…多分あなたは心配する必要があります。

しかし、あなたはこれを言います。強調は私のものです:

これらの攻撃はrootを試みることから始まりましたが、その後ユーザーアカウントを試みるようになり、正しいユーザー名をどのように推測したかはわかりません(パスワードは間違っていますが) 。

いくつかのユーザー名がシステム上のユーザーと一致していても、ランダムに名前が付けられたアカウントが「ハッキング」されていても心配する必要はありません。

つまり、彼らは「ユーザーアカウント」を試みていると言いますが、どのユーザーですか?システム上の有効なユーザーと一致していますか?システム上の有効なユーザーと一致しない場合でも、心配する必要はありません…時々、Tomcatまたはtestuserとしてログインしようとする試みが見られます。これらのボットは、ライブラリにある数十、数百、数千のユーザー名を循環して、どのアカウントにアクセスできるかを確認しています…そして、これで眠りにつくことはありません。

しかし、「ハッキング」の試みがpurely特定の/既知のアカウントに対するものである場合はどうでしょうか?その後、あなたは心配する必要があります。

とはいえ、どういうわけか攻撃がonlyをシステム上に存在するユーザーを標的にしている場合、ハッカーはどういうわけかあなたの/etc/passwdのコピーを入手したと推測できます。ファイル。まず、passwdの履歴名にもかかわらず、ファイルにはユーザーパスワードではなく、基本的なユーザー情報が含まれています。そして、攻撃者がその/etc/passwdファイルを持っている場合、はるかに大きな問題が発生します

特定の/既知のアカウントが「ハッキング」されている場合、Webアプリケーションがハッキングされている可能性があります。

通常、Webサーバーでは、侵害の主なポイントはnotSSHなどを介して、ただしWebアプリケーション/サーバー自体を介してです。つまり、WebサイトがWordPressまたはJoomla!のような既知のCMSシステムに基づいている場合、ハッカーはそのWebアプリケーションを介してシステムに侵入し、より深いレベルでシステムに侵入しました。これは、SSHアクセスを持っているのと同じですが、ディープSSHアクセスは持っていません。

つまり、Apacheなどのソフトウェアで実行されているWebサーバーは、www-dataなどのroot以外のユーザーによって管理されます。 Webアプリケーションの侵害は、ハッカーがApacheと同じレベルのアクセス権を持っていることを意味しますが、「書き込み」レベルではそれほど深くはありません…それでも「読み取り」レベルでは恐ろしいレベルのアクセス権があります。

したがって、サーバー上のWebアプリケーションがハッキングされ、ペイロードがApacheユーザーレベルでサーバーにドロップされ、侵害されたアクセスを介して/etc/passwdファイルを取得した可能性があります。そして今、彼らはその/etc/passwdファイルのユーザー名を介してエントリを取得しようとしています。

Webアプリケーションがハッキングされた場合の対処方法。

だからあなたは怖がるべきですか?そのシナリオが当てはまる場合は、はい。しかし、Fail2banは今あなたを救うことはできません。 rootを無効にしても、ある程度節約できます。ただし、Webアプリケーションが危険にさらされている場合は、クリーンアップする必要があります。 SSHの試みは、すでに何かに感染しているサーバー上で「グレイビー」をハッキングしているだけです。

Webアプリケーションをクリーンアップするにはどうすればよいですか?簡単な答えはありませんが、たとえばWordPressを使用している場合は、WordPress)を再インストールしてから、バックアップを介してサイトのカスタマイズを再インストールすることを検討してください。

そしてそうです…このようなものが、バックアップとコード回復管理が重要な理由です。しかし、ここでは誰も、現時点でどのようにアプローチすべきかを説明することはできません。これはまったく別の質問であり、cPanelの使用に基づいて、外部の技術者からの追加の支援が必要になる場合があります。しかし、それについて言及する必要があります。

4
JakeGould

iptablesを介してボックスへのアクセスをドロップする疑わしい試み(繰り返しに基づく)をブロックすることにより、この種のブルートフォース攻撃を阻止することができます。

この場合、 Fail2Ban という非常に便利なツールがあります。このツールは基本的にいくつかのログファイルをチェックし、構成で定義したパターンを探して失敗します。同じIPからY秒にX回の試行があった場合、IPは一定時間ブロックされるため、それ以上試行できません。

あなたが言うように、Dev-opsはあなたの得意ではありません、 リンクがあります これは必要な部分を非常によく示しているので、それほど混乱することなく機能します。したがって、ブルートフォースの試みがログに記録されているログファイルを見つけて、新しい刑務所を定義する必要があります。これは、上記の組み合わせにすぎません。おそらく最も「難しい」のは、これらのエントリに一致するパターンを取得することです。正規表現に基づくログファイル内。ヘルプが必要な場合は、これらの行のいくつかで質問を更新できます。一致する正規表現の合成をお手伝いします。

残りはデーモンを起動するだけで、これらのブルートフォース攻撃についてはもう心配する必要はありません。

:Fail2Banで定義されている組み込みのjailがすでにいくつかあり、SSHのように非常にうまく機能します。

1
nKn