Linuxサーバーの保護：iptablesとfail2ban

Linuxサーバーのセキュリティ、特にブルートフォース攻撃とfail2banとカスタムiptablesの使用に関するコミュニティの頭脳を取り上げたいと思います。

似たような質問がいくつかありますが、どれも私の満足するトピックには対応していません。手短に言えば、ブルートフォース攻撃からインターネットに公開されているLinuxサーバー（通常のサービス、ssh、web、メールを実行している）を保護するための最良のソリューションを決定しようとしています。

私はサーバーのセキュリティにまともなハンドルを持っています。つまり、ルートまたはパスワードのログインを許可しない、デフォルトのポートを変更する、ソフトウェアが最新であることを確認する、ログファイルをチェックする、特定のホストのみがサーバーにアクセスできるようにすることでsshをロックし、セキュリティを利用する一般的なセキュリティコンプライアンスのためのLynis（https://cisofy.com/lynis/）などの監査ツールなので、入力やアドバイスはいつでも歓迎しますが、この質問は必ずしもそれに関するものではありません。

私の質問は、どのソリューションを使用するか（fail2banまたはiptables）、それをどのように構成するか、または両方の組み合わせを使用してブルートフォース攻撃から保護するかです。

トピックに関して興味深い応答があります（Denyhosts対fail2ban対iptables-ブルートフォースログオンを防止する最善の方法？）。私個人にとって最も興味深い答えは（https://serverfault.com/a/128964）であり、ログファイルを解析するためにユーザーモードツールを使用するfail2banとは対照的に、iptablesルーティングはカーネルで発生します。Fail2banはもちろんiptablesを使用しますが、アクションを実行するまで、ログファイルを解析してパターンを照合する必要があります。

次に、iptablesを使用し、レート制限（https://www.rackaid.com/blog/how-to-block-ssh-brute-force-attacks/）を使用してIPからのリクエストを一定期間ドロップすることは理にかなっていますか接続しようとしていたプロトコルに関係なく、特定の期間中に接続試行が多すぎる時間の割合 もしそうなら、ここでそれらのパケットにドロップと拒否を使用することについていくつかの興味深い考えがあります（http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject）、それについての考えはありますか？

Fail2banでは、デフォルトの構成では対応できない可能性のあるサービスのカスタム「ルール」を記述できる形式でカスタム構成が可能です。インストールと設定は簡単で強力ですが、xの量を超えてサービス/プロトコルで2回失敗した場合、サーバーからIP を「ブロック」するだけで済むとしたら、やりすぎかもしれません。時間の？

ここでの目標は、毎日のログウォッチレポートを開くことであり、サーバーへの接続に失敗したページをスクロールする必要はありません。

お時間をいただきありがとうございます。

fail2banまたはiptablesを使用する必要がありますか？

ファイアウォールソリューションに加えて fail2ban を使用して、既存のファイアウォールルールをオンデマンドで拡張し、他の方法ではパブリックサービスで望ましくないアクションを実行するシステムの特定のIPアドレスをブロックするルールを追加します。彼らは互いに協調して働きます。

簡素化：ファイアウォールはネットワーク接続とパケットのみを認識し、そのパターンをある程度理解できますが、アプリケーションレベルの洞察では、望ましいリクエストと有効なリクエストを、悪意のある不正なリクエストから区別できません。たとえば、ファイアウォールは、一連のHTTP APIリクエストと、Wordpress管理ページでのブルートフォースパスワード推測による誤ったログイン試行回数の違いを区別できません。ファイアウォールでは、どちらもポート80または443へのTCP接続のみです。

Fail2banは、多少間接的ではありますが、ファイアウォールにそのアプリケーションレベルの洞察を提供する、汎用的で拡張可能なアプローチです。
多くの場合、アプリケーションは悪意のある不正なリクエストを登録してログに記録しますが、それ以上の乱用を防止するネイティブの機能を備えていることはまれです。Fail2banはわずかに分離されていますが、ログに記録された悪意のあるイベントに対処し、通常はファイアウォールを動的に再構成してそれ以上のアクセスを拒否することにより、被害を制限し、さらなる悪用を防ぐことができます。言い換えれば、Fail2banは既存のアプリケーションを変更せずに、不正使用を防ぐ手段を提供します。

ファイアウォールにアプリケーションレベルの洞察を提供する別の方法は、侵入検知/防止システムによるものです。

たとえば、ウェブサーバーは一般的な公共サービスであり、ファイアウォールではTCPポート80および443がインターネット全体に開かれています。
たとえば、NATゲートウェイやWebプロキシの背後にいる複数の有効なユーザーが単一のオリジンを持つことができるため、通常、HTTP / HTTPSポートにレート制限はありません。

Webサーバーに対する望ましくないアクションや悪意のあるアクションを検出した場合、fail2banを使用して、そのような違反者のブロックを自動化します（完全にブロックするか、ポート80および443へのアクセスをロックするだけで）。

一方、SSHアクセスはパブリックサービスではありませんが、ファイアウォール内のSSHアクセスをホワイトリストのIPアドレス範囲のみに制限する立場にない場合は、着信接続をレート制限することでブルートを遅くすることができます -強制攻撃。しかし、ファイアウォールは、ボブがansibleプレイブックを実行していることと、ボットによるrootとしてのログインに5回失敗したため、5回ログインに成功したユーザーbobを区別できません。

fail2banまたはiptablesを使用する必要がありますか？

これは、「シートベルトと車のどちらを使うべきか」と尋ねるのと似ています。

まず、fail2banはテキストファイル内の繰り返し発生するエントリを自動的に検出し、指定されたしきい値に達したときにコマンドを実行するためのツールにすぎないことを覚えておいてください。

ポリシー違反を示す繰り返しのログエントリによって示されるように、ポリシーに違反するホストをブロックするためによく使用されますが、それだけを使用できるわけではありません。

あなたはできる追加（および削除）するfail2banの使用オンデマンドでのルールをiptablesの。iptablesルールを手動で追加および削除することもできます。あるいは、fail2banを使用して、まったく異なる応答を行うこともできます。それはあなたがそれをどのように構成するかについてのすべてです。

fail2banを実行しているかどうかに関係なく、一般的なファイアウォールを設定する必要があります。このようなファイアウォールは、たとえば、正当ではないことがわかっている（受信または送信）トラフィックをブロックするためのものです。たとえば、そのデータベースサーバーは、インターネット全体からのポート25での着信接続を本当に処理する必要があるのでしょうか。

その上、fail2banが問題のIPをしばらく遮断することでポリシー違反に応答しても、サーバー自体を保護することはできません（優れたエクスプロイトはファイアウォールを1回通過するだけで十分です）。システムログを含むがこれに限定されない、システムのノイズレベルを削減します。これを行う簡単な方法は、fail2banでiptablesを実行して、しばらくの間パケットをドロップするようにカーネルを構成することです。ホストファイアウォールだけでなく、境界ファイアウォールを再構成できる場合は、それだけで十分です。

つまり、そもそもそれらを簡単に分離できる範囲で、両方が必要です。

私が達成しようとしているのは、サービス/プロトコルで2回失敗したアクセス試行をサーバーから2回失敗した場合にサーバーからIPを「ブロック」することだけだとしたら、やりすぎかもしれません。

それはまさに fail2banが解決するように設計されているユースケースです。本来の目的でツールを使用することは、決してやり過ぎではありません。

ここでの目標は、毎日のログウォッチレポートを開くことであり、サーバーへの接続に失敗したページをスクロールする必要はありません。

余談ですが、質問とは直接関係ありません。レビューのためにログをフィルタリングする場合は常に、特定のエントリに対して何をするかを検討してください。エントリに関して「meh」と言って次に進むだけの場合は、おそらくそれを除外する必要があります。必要に応じて、確認のために完全なログを保存してください。ただし、通常の監視ワークフローには、表示されたときに実際に何かを行うことになるもののみをプッシュしてください。数回の接続試行の失敗後にホストをブロックするようにfail2banを設定した場合、それらを手動で確認する必要がなく、監視通知から削除できる可能性はかなり高いです。正当なユーザーがアクセスの喪失について不平を言った場合は、完全なログを取り出して確認してください。

同じ質問を数年前に解決しました。パフォーマンスと簡単なセットアップのため、最近のモジュールでiptablesを使用することにしました。ホスト上の多くの仮想コンテナーを保護する必要がありました。ルールでDOSベクターを開かないように注意してください。また、ipsetを使用して、ルールのネットワークリストまたはIPリストを照合します。ホワイトリストに使用します。1つのリストの1つの国のすべてのネットワークは、微調整に最適です。さらに、照合するポートをもう1つ追加するだけで、同じルールセットで他のサービスを保護するのは非常に簡単です。したがって、私はfail2banで変更するのは好きではありませんが、他のニーズを持つ誰かがfail2banで満足するでしょう。

ここにいくつかのサンプルがあります：

  #
  # SSH tracking sample
  #
  #################################################################################
  iptables -X IN_SSH
  iptables -N IN_SSH
  iptables -A IN_SSH -m set --match-set net_blacklist src -p tcp -j REJECT
  iptables -A IN_SSH -m set --match-set net_whitelist src -p tcp --match limit --limit 5/second -j LOG --log-prefix whitelist_de_prefix
  iptables -A IN_SSH -m set --match-set net_whitelist src -p tcp -j ACCEPT
  # filter update
  iptables -A IN_SSH -m recent --name sshbf --set --rsource
  # connlimit
  iptables -A IN_SSH -m connlimit --connlimit-above 4 --match limit --limit 5/second -j LOG --log-prefix ssh_connlimit_per_ip_above_4
  iptables -A IN_SSH -m connlimit --connlimit-above 4 -j REJECT
  # filter
  iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 13 --seconds 60 --match limit --limit 5/second -j LOG --log-prefix ssh_filtered_13in60sec
  iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 13 --seconds 60 -j REJECT
  iptables -A IN_SSH -j ACCEPT

iptables -A FORWARD -p tcp --dport ssh --syn --jump IN_SSH
# iptables -A INPUT -p tcp --dport ssh --syn --jump IN_SSH

ロギングメッセージの出力は、fail2banと組み合わせることができます。INPUTルールにも使用できます。