web-dev-qa-db-ja.com

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

Linuxサーバーのセキュリティ、特に総当たり攻撃およびfail2ban vsカスタムの使用に関するコミュニティの頭脳を取り上げたいと思います- iptables。

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

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

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

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

次に、iptablesを使用してrate-limited（ https://www.rackaid.com/blog/how- to-block-ssh-brute-force-attacks / ）接続しようとしたプロトコルに関係なく、特定の期間中に接続試行が多すぎるIPからの要求をドロップするには？もしそうなら、それらのパケットに対してドロップvsリジェクトを使用することについていくつかの興味深い考えがあります（ http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject ）、それについて何か考えはありますか？

Fail2banでは、デフォルトの構成では対応できない可能性のあるサービスに対して、カスタム 'rules'を書き込むことができる形式でカスタム構成が可能です。インストールと設定は簡単で強力ですが、サーバーでIPを「block」して2回アクセスに失敗した場合、やり過ぎになる可能性があります。 x時間にわたるサービス/プロトコル？

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

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

sshsecurityiptablesfail2banbrute-force-attacks
10
kingmilo

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

Fail2ban に加えてファイアウォールソリューションを使用して、extendon-demandこれらの既存のファイアウォールそれ以外の場合はパブリックサービスで望ましくないアクションを実行するシステムの特定のIPアドレスをブロックするルールを含むルール。彼らは互いに協調して働きます。

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

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

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

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

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

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

21
HBruijn

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

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

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

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

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

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

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

つまり、最初から簡単に分離できる範囲で、両方が必要です。

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

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

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

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

7
a CVn

同じ質問を数年前に解決しました。パフォーマンスと簡単なセットアップのため、最近のモジュールで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ルールにも使用できます。

4
Rainer