Fail2Ban Plesk Fail2Banは、わずか数クリックでブルートフォース攻撃からPleskサーバ環境を効果的に保護し、疑わしいIPを自動的にブロックします。Fail2Banのインストール、ジェイルの有効化、ルールのカスタマイズ、通知の設定方法を順を追って説明します。 サーバー は永久にクリーンなままである。
中心点
パネルでの実装方法を詳しく説明する前に、以下のキーポイントで概要をコンパクトに説明する。正しい設定方法 優先順位 最初から
- インストール ツール＆設定」経由で、即座に有効化
- 刑務所 SSH、メール、Pleskパネル、WordPressに特化して使用する
- パラメータ 禁止時間、検出ウィンドウ、失敗した試行など
- ホワイトリスト 信頼できるIPの維持とブロックのチェック
- モニタリング ログの微調整を行い、誤報を減らす。
Fail2Banは何をするのか - 簡単な説明
Fail2Banの分析 プロトコル SSH、メール、ウェブサーバー、Pleskパネルなどのサービスの試行が繰り返し失敗することを認識します。IPが定義されたしきい値を超えた場合、設定された期間、自動的にブロックします。このようにして、ブルートフォース、辞書攻撃、自動スキャンを最小限の労力で確実に防いでいます。 支出.Pleskは明確なインターフェイスを提供しており、そこでジェイルのオン/オフを切り替えたり、パラメータを調整したりすることができます。生産性の高いサーバにとって、この保護は最も迅速な対策の1つであり、顕著な効果があります。
Pleskへのインストール：前提条件と開始
現在のPleskサーバーは リナックスをObsidianにインストールし、まずFail2Banコンポーネントがすでに存在するかどうかを確認します。見つからない場合は、Pleskの「ツールと設定」を開き、「更新とアップグレード」から「コンポーネントの追加と削除」を選択します。そこでFail2Banのエントリを有効にして、Fail2Banを起動します。 インストール.完了すると、ブロックIPアドレス（Fail2Ban）のセクションが表示され、この機能をオンにして監視する。完全なセットアップのために、私はFail2Banとうまく設定されたファイアウォールを組み合わせている。 Pleskファイアウォールの設定.
基本設定：適切なデフォルト値を選択
スイッチを入れた後、私は効果と誤報を決定するグローバル・パラメーターをチェックする。バランスの取れた 禁止時間 正当なユーザーを永久に締め出すことなく、攻撃者を締め出すことができます。検出ウィンドウは、Fail2Banが失敗した試行を収集する時間を制御し、失敗した試行の最大数は、ブロックのしきい値を設定します。また、重要なイベントをすぐに確認できるように、通知用の電子メールアドレスを入力しています。次の表は、多くのセットアップで証明され、いつでも改良できる一般的な開始値を示しています。
| パラメータ | 推薦 | 効果 |
|---|---|---|
| 禁止時間 | 600～1800秒 | ユーザーを永久にロックアウトすることなく、攻撃者を顕著にブロック |
| 認識ウィンドウ | 300～600秒 | 合理的な期間でのテストの集計 |
| マックス失敗した試行 | 3-5 | 偽陽性を減らし、なおかつ厳格さを保つ |
| お知らせ | 電子メールの有効化 | ロックダウンや重要なイベントに関する警告 |
加えて、私は冒頭で 無視リスト (ホワイトリスト）をグローバルレベルで設定します。ツールと設定＞ブロックIPアドレスで、私は静的なオフィスIPアドレス、VPNエンドポイント、または管理ネットワークを入力します。IPv6については、一貫性のあるプレフィックス（/64など）を注意して使用し、保護が損なわれないようにリストを無駄のないものにしている。繰り返し問題を起こす人には 禁止時間の増加 を証明した：以下のようなパラメータがある。 bantime.increment = true, バンタイム・ファクター そして バンタイム・マクスタイム 繰り返せば自動的にロックが伸びるので、効果が持続する。
刑務所：サービスの対象となる保護
監獄タブで、最も重要な保護ルールを有効にする。 サービス内容sshd, dovecot, proftpd, plesk-apache, plesk-panel と plesk-wordpress です。各ジェイルは、一致するログファイルを監視し、パターンを認識し、目立つIPをブロックします。WordPressのインスタンスがあるサーバーでは、wp-loginとxmlrpcのログイン攻撃をブロックするために、plesk-wordpressをオンにする。FTPが実行されていない場合は、サーバーが不要なチェックを行わないように、関連するジェイルを非アクティブにする。そして、ブロックが確実に機能するかどうかをチェックし、誤検知が多ければ閾値を調整します。
オリエンテーション: sshd は通常、次の場所から読み込みます。 /var/log/auth.log (Debian/Ubuntu)または /var/log/secure (RHEL/Alma/Rocky)では、メールログインは結局 /var/log/maillog それぞれ /var/log/mail.logパネルがログインする /var/log/plesk/panel.log.Web 攻撃の場合、Plesk jail は以下のバーチャルホストログにアクセスします。 /var/www/vhosts/system//logs/ に変更してください。NGINX または Apache+NGINX セットアップのみを実行している場合、適切なパスがすでに保存されているため、Plesk フィルタは引き続き機能します。
独自のジェイルとフィルターをクリーンに作成
追加で必要ですか？ 保護 アプリケーションのために、私は新しいjailを作成し、関連するログを参照します。私は、明確なタイムウィンドウを定義し、失敗の限界を設定し、望ましい禁止時間を決定する。特別なアプリケーションのために、私は特定のエラーメッセージを認識する正規表現でフィルタを書く。ルールを有効にした後、失敗した試みをシミュレートしてログをチェックすることでテストする。攻撃者が迂回できるパターンに気づいたら、フィルターを改良し、その変更をログに記録する。 ドキュメンテーション.
カスタマイズがアップデートセーフであることを保証するために、私は 独自の構成 に於いて /etc/fail2ban/jail.d/ を別ファイルとして使用する（例 カスタム・ワードプレス・ローカル)の標準ファイルを変更するのではありません。こうすれば、Pleskやパッケージのアップデートでルールが上書きされることはありません。フィルタルールをテストするには fail2ban-regex を生成するためにjailを切り替える前に、サンプルログと比較します。変更後 systemctl reload fail2banハードリスタートなしでアクティブにする。
ホワイトリスト、ブロックの解除、ブロックされたIPの把握
自分自身やチームメンバーをブロックした場合は、ブロックしたIPアドレスのリストを開き、再度ブロックを解除します。恒久的に信頼できる情報源については、ホワイトリストを使用し、将来的なブロックを防止している。 閉塞.概要では、どのジェイルがIPをブロックし、どのルールで検出されたかを見ることができます。この情報は私が誤った設定のアプリケーションやボットを認識するのに役立ちます。私はホワイトリストを無駄のない状態に保ち、そうする正当な理由がある場合にのみエントリを維持します。 理由 そこに
の後ろで働いているのか？ プロキシ/CDN私はホワイトリストに特に注意を払う：ログインとウェブアクセスがサーバから見てリバースプロキシのIPの後ろにある場合、不注意に設定されたジェイルは、最悪の場合、実際の攻撃者の代わりにプロキシをブロックしてしまう。この場合、私は、ウェブサーバが "本当の "クライアントIPをログに正しく書き込むことを確認し(X-Forwarded-For/Actual Real-IPメカニズム)、プロキシネットワークを信頼できるものとして維持します。これにより、ブロックの正確性が保たれます。
ミスを避ける：実践から得た賢明なチューニング
まずは控えめに しきい値 そして、典型的な負荷と使用プロファイルがわかってから値を厳しくします。多くのユーザがいる共有ホストの場合、誤ブロックのリスクが高まるので、私はMaxRetryを高く設定し、ログをより注意深く監視します。ボットがフォームに到達する場合は、ウェブサーバーのログとplesk-apache jailの追加ルールを見てみる価値があります。私は管理者ログインのために2FAをセットアップし、その結果、パネルに到着するログイン試行が少なくなったので、Fail2Banを緩和した。ブロックリストを定期的に見ることで、個々の ソース は特に目立っており、さらなる対策が必要だ。
ファイアウォールの組み合わせとWordPressの堅牢化
Fail2Banは試行が失敗した後に攻撃者をブロックし、ファイアウォールは攻撃対象領域を事前に縮小する。両者を併用することで、以下のような効果が得られます。 セキュリティ特にSSHやメールポートが公開されている場合は。WordPressの場合、私はxmlrpcを制限し、アプリケーションレベルでログイン率の制限を設定し、残りの作業はplesk-wordpressに任せています。これにより、単一のバリアではなく、徹底的な防御が可能になります。より詳細な比較はこちらの記事をご覧ください： Fail2Banとファイアウォールの比較そして、その対策を調整する手助けをしてくれる。
Plesk管理者のための実用的なチェック
セットアップが完了したら、予定時間内にロックがかかるかどうか、Eメール通知が届くかどうかをチェックする。その後、わざと間違ったパスワードでSSHをテストし、ログをチェックして、SSHの有効性を確認する。 刑務所 を確認してください。Pleskパネルでは、ログインに何度か失敗するシミュレーションを行い、IPが速やかにブロックされるかどうかを観察します。正当なブロックが多すぎる場合は、MaxRetryを段階的に増やし、検出ウィンドウを適度に拡張します。この一貫したアプローチにより、誤報が最小限に抑えられ、静かなログインが保証されます。 オペレーション.
ホスティングの統合：私が気をつけていること
強力なホスティング設定は、首尾一貫した方法でFail2Ban、ファイアウォール、バックアップおよび監視を提供します。私は、Pleskの直接統合、サポートにおける短い応答時間、および明確な ドキュメンテーション.分離されたサービス・コンテナと一貫したカーネル・アップデートを備えたプロバイダーは、私にさらなるセキュリティを提供してくれる。生産的なプロジェクトでは、緊急時にすぐにオンラインに戻れるよう、オフサイト・バックアップにも頼っている。これによって、攻撃をはるかに困難にし、合理的なセキュリティ・レベルを実現することができる。 支出 を維持することができる。
モニタリングとトラブルシューティング：常に状況を把握する方法
私は定期的にFail2Banの概要を分析し、ブロックされたものをチェックしている。 住所 そして、繰り返されるソースを認識する。パターンが見つかったら、フィルタールールを調整し、後で追跡できるように変更を文書化する。ログに高負荷のピークがあれば、ウェブサーバーに追加の制限を設定し、ファイアウォールを強化します。同時に、Plesk、システムパッケージ、プラグインを常に新鮮な状態に保ち、攻撃の可能性を最小限に抑えます。 Pleskのセキュリティギャップを埋める.これにより、Fail2Ban の保護が最新の状態に保たれ、Fail2Ban の必要性が少なくなります。 労働 を実行する。
Plesk でのプロトコルのバックエンドとパス
信頼性の高い検出を行うには、Fail2Banが適切な機能を備えていることが極めて重要です。 プロトコル・ソース を読む。Linuxでは、ディストリビューションによって、ファイルログかsystemdバックエンドを使う。最近のセットアップでは バックエンド = systemdFail2Banはジャーナルを直接読み込むため、ログファイルへのI/Oが少なくなります。Pleskには、このための賢明なデフォルト設定がすでにあります。それでも、ジェイル内のログパスが現実に一致しているかどうかをランダムにチェックします。 /var/log/auth.log (Debian/Ubuntu)または /var/log/secure (RHEL/Alma/Rocky)、メール・イン /var/log/maillog 或いは /var/log/mail.logのPleskパネル /var/log/plesk/panel.logvhostディレクトリのWeb。パスやジャーナル名が正しくない場合は、別の ローカル-ファイル。こうすることで、攻撃が検知されないままになってしまう盲点を避けることができる。
IPv6、バナクション、ファイアウォール・バックエンド
多くの施設では、もはやIPv4だけをフィルタリングしているわけではない。私は バナクション はIPv6に適している（iptables/firewalldのマルチポートバリアントなど）。システムがFirewalldを使用している場合、私は以下のようなアクションに注意を払う。 ファイアウォールcmd-マルチポート古典的なiptablesの設定には マルチポート またはipsetベースのアクションを使用すると、パフォーマンスが向上します。Fail2Banで使用されるアクションが、アクティブなPleskファイアウォールと一致することが重要です - そうでなければ、ブロックは間違ったチェーンに終わるか、またはまったく効果がありません。変更後、私は具体的にテストします: テストIPからの失敗した試行のシミュレーション、jailのステータスクエリ、そして接続テスト。IPv6ブロックが確実に機能すれば、混合ネットワークで見過ごされがちな重要なギャップを埋めることができます。
エスカレートする監禁と長期的な阻止（再犯）
繰り返し攻撃する選手には、プレッシャーを強める。 禁止時間の増分 (バンタイム・インクリメント)のロックは自動的に延長される。 バンタイム係数 = 2 - 常識的な最大値(バンタイム・マクスタイム).また 刑務所 これは、より長いウィンドウの中で異なる監獄に何度も現れるIPを検出するものである。コンフィギュレーションは ファインドタイム 数時間から数日の範囲で、数日間の禁止期間が効果的であることが証明されています。このレベルは、合法的なユーザーを永久に排除することなく、定期的に戻ってくるボットに対して持続的な効果をもたらします。を介して信頼できるネットワークを使用することが重要であることに変わりはありません。 無視IP また、ブラックリストを通じて効果を監視することもできる。
CLIワークフロー：チェック、リロード、ロック解除
Pleskは便利なインターフェイスを提供していますが、私は多くの問題を解決しています。 速い コンソールを介してと fail2ban-clientステータス 現役の刑務所が見える、 fail2ban-clientステータス <jail ブロックされたIPとカウンターをリストアップします。新しいルールは systemctl reload fail2ban必要であれば、サービスを再起動します。個々のIPを削除するfail2ban-client set unbanipシステム全体に影響を与えることなく）。トラブルシューティング journalctl -u fail2banを使用して、不具合のあるフィルターに関する情報など、最新のイベントを読むことができます。これによって、無駄のないオペレーションを維持し、介入を簡潔に文書化し、発見をルールにフィードバックすることができる。
プロキシ/CDN、ModSecurityとWordPressの詳細の背後にある操作
今日、多くのウェブサイトは、その背後にぶら下がっている。 リバースプロキシ またはCDNを使用しています。Fail2Banが実際のクライアントを確実に評価するために、私はウェブサーバーがログに正しいIPを記録していることと、プロキシネットワークがホワイトリストに載っていることを確認している。そうしないと、意図せずエッジネットワーク全体をブロックしてしまう危険性があるからです。また、Pleskでは ModSecurity (WAF）：ModSecurityはHTTPレベルで既知の攻撃パターンをブロックし、Fail2Banは失敗したログイン試行や繰り返される4xx/5xxパターンを制裁する。WordPressの場合、私は2つのアプローチを取っている：xmlrpcを制限するかセキュアにする。 Plesk-Wordpress-jailをアクティブにする。こうすることで、ログのノイズを取り除き、Fail2Banに難しいケースを狙わせることができる。
メンテナンス、バックアップ、アップデート戦略
調整を長期的に持続させるために、私はすべての調整項目を保管している。 独自ルール の下にある別々のファイルに /etc/fail2ban/jail.d/ そしてバージョンごとの変更を文書化します。pleskやシステムの大きなアップデートの前には、スナップショットやバックアップを作成し、ジェイルがまだ有効かどうか、パスが正しいかどうかをランダムにチェックします。また、ログのローテーションも考慮に入れています。ローテーションの実行（新しいログファイル）の後、バックエンドは確実に読み取りを続けなければなりません - systemd-Journalを使えば、この懸念はほとんどなくなります。私はチームのために短いSOPを確立します：どのようにIPが禁止解除され、閾値が調整され、通知がチェックされるか。これにより、担当が変わっても一貫した取り扱いができるようになります。
法的判断：プロトコルと保管
セキュリティも必要だ。 寸法.私は、防御と診断に必要な情報のみを保存し、明確な保存期間を設定し、古いデータを定期的に削除します。Fail2Ban自体は、長期間のデータを保存しません。基本は、お客様のシステムとウェブログです。通常の操作では、ログレベルを下げて（INFOなど）データ量を管理し、分析のために一時的にDEBUGに上げ、また元に戻します。こうして、効果的な保護と無駄のない追跡可能なデータ追跡を両立させている。
一言で言えば、数クリックでセキュアな実装が可能です。
Plesk経由でFail2Banを有効にし、バランスの取れたパラメータを設定し、適切なスイッチを入れます。 刑務所 そして、無駄のないホワイトリストを維持しています。補完的なファイアウォール、2FA、クリーンアップデートを使用することで、私はバラストなしで高レベルの保護を実現しています。カスタマイズされたフィルターが特殊なケースをコントロールし、通知とログが日々の作業を簡素化してくれる。これらのステップを心に留めておけば、ブルートフォース（総当たり攻撃）の試行を大幅に減らし、管理者ログイン、メール、SSH を効率的に保護することができます。Pleskサーバを安全に保つ方法 フェイルツーバン 永続的な回復力があり、投与が容易である。
