Denyhosts vs fail2ban vs iptables-ブルートフォースログオンを防ぐ最善の方法？
LAMPサーバーをセットアップしていて、SSH/FTPなどを防ぐ必要があります。総当たりのログオン試行が成功しない。 denyhostsとfail2banの両方について多くの推奨事項を見てきましたが、2つの比較はほとんどありません。また、IPTablesルールが同じ機能を満たすことができることも読みました。
これらの方法のいずれかを他の方法よりも選ぶのはなぜですか？ serverfaultの人々はこの問題をどのように処理しますか？
IIRC、DenyHostsはSSHサービスのみを監視します。他のサービスも保護する必要がある場合は、Fail2banの方が間違いなく適しています。構成を微調整する場合は、ほぼすべてのサービスを監視するように構成できますが、Fail2banの新しいバージョンには、多くの一般的なサーバーデーモンに適したルールセットが含まれているため、その必要はありません。単純なiptablesレート制限に対してfail2banを使用すると、攻撃者がサーバーを攻撃する速さを単に減らすのではなく、指定された時間にわたって攻撃者を完全にブロックするという利点があります。私はfail2banを使用して多くの実稼働サーバーで素晴らしい結果を出しており、使用を開始して以来、これらのサーバーのいずれかがブルートフォース攻撃によって破られるのを見たことはありません。
ブルートフォースログオンを防ぐ最善の方法は？
そもそも彼らがあなたのマシンに到達しないようにしてください！ホストに到達する前に、またはSSHレベルでさえ、総当たり攻撃を阻止する方法はたくさんあります。
そうは言っても、fail2banのようなものでオペレーティングシステムを保護することは素晴らしいアイデアです。 Fail2banはDenyHostsとは少し異なりますが、同じスペースで再生されます。 Fail2banはiptablesを使用します。
http://en.wikipedia.org/wiki/Fail2ban
Fail2banはDenyHostsに似ていますが、SSHに焦点を当てたDenyHostsとは異なり、fail2banは、ログファイルにログイン試行を書き込むサービスを監視するように構成でき、/ etc/hosts.denyを使用してIPアドレス/ホストのみをブロックする代わりに、fail2banはNetfilter/iptablesとTCP Wrappers /etc/hosts.deny。
ブルートフォースログインを防止するために検討する必要のある重要なセキュリティ技術がいくつかあります。
SSH：
- Rootのログインを許可しない
- Sshパスワードを許可しない（秘密鍵認証を使用）
- すべてのインターフェースをリッスンしないでください
- SSHのネットワークインターフェース（eth1など）を作成します。これは、リクエストを処理するインターフェース（eth0など）とは異なります。
- 一般的なユーザー名を使用しない
- 許可リストを使用し、SSHアクセスを必要とするユーザーのみを許可する
- インターネットアクセスが必要な場合...有限のIPセットへのアクセスを制限します。 1つの静的IPが理想的ですが、それをx.x.0.0/16にロックすることは0.0.0.0/0よりも優れています
- 可能であれば、インターネットアクセスなしで接続する方法を見つけて、その方法でSSHのすべてのインターネットトラフィックを拒否できます（たとえば、AWSでは、インターネットをバイパスする直接接続を取得できます。これをダイレクトコネクトと呼びます）
- Fail2banなどのソフトウェアを使用して、ブルートフォース攻撃をキャッチする
- OS、特にセキュリティとsshパッケージが常に最新であることを確認する
応用：
- アプリケーション、特にセキュリティパッケージが常に最新であることを確認する
- アプリケーションの「管理」ページをロックダウンします。上記のアドバイスの多くは、アプリケーションの管理領域にも当てはまります。
- 管理領域をパスワードで保護します。Webコンソールのhtpasswdのようなものは、根本的なアプリケーションの脆弱性を投影し、エントリへの追加の障壁を作成します
- ファイルのアクセス許可をロックダウンします。 「フォルダのアップロード」は、あらゆる種類の厄介なもののエントリポイントであることで有名です。
- アプリケーションをプライベートネットワークの背後に置き、フロントエンドロードバランサーとジャンプボックスのみを公開することを検討してください（これはAWSでのVPCを使用した一般的な設定です）
SSHを保護するもう1つの素晴らしい方法（これを10年以上使用しています）は、（ディストリビューションによっては）iptablesの最近のライブラリをネイティブで使用することです。
基本的には、iptablesに組み込まれたポートノッキングとして使用できます。これはあなたの頭痛の多くを保存します。 tcp接続できる限り（telnetは1つの方法です。私はsshクライアントも使用し、それらをポートに向けました。指定されたポート番号へのtcp接続を行うものは何でも。私はPuTTYを探しています！） ssh接続を開始するクライアントはこれを使用できます。
以下は、ホストからポート4103でサーバーにTelnetで接続するときに、iptablesがホストに対してポート22を開く例です。次に、ポート4102または4104へのTelnetを使用して、sedの開始を閉じることができます。 4102と4104の両方の理由は、単純なtcpスキャンが22を開かないようにするためです。ポート4103へのtcp connect（telnet）のみが許可されます。
楽しい！
ああ、私はFail2Banを支持しています。より柔軟性があり、禁止がtcpwrappersではなくiptablesで発生するのが好きです。
SSHポートノッキング
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m recent --rcheck --name SSH -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4102 -m recent --name SSH --remove -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4103 -m recent --name SSH --set -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4104 -m recent --name SSH --remove -j DROP
私はiptablesルールを使用して、同じIPアドレスからの新しい接続をレート制限します（主にSSHですが、FTPでも問題なく機能します）。 「fail2ban」や他のそのようなツールに対する私が見るところの利点は、iptablesルートが完全にカーネルモードで発生し、ログファイルをテール/解析するためにユーザーモードツールに依存しないことです。
それが可能であれば、問題のプロトコルにアクセスできるソースアドレスを制限することも明らかに役立ちます。
SSHでは、証明書認証を使用し、いずれにしてもパスワードを受け入れないようにする必要があります。
Fail2banとDenyhostsのもう1つの違いは、Denyhostsが他のDenyhostsユーザーとブロックリストを共有できることです。 Fail2banを使用すると、サーバーが以前に確認したIPのみをブロックできます。Denyhostsを使用すると、ブルートフォース攻撃がサーバーに到達することはなく、他の誰かがそれを確認した場合、ブロックリストは攻撃者の前にサーバーにダウンロードされます。あなたのコンピュータに到達します。
さらに別の違いは、Fail2banがiptablesを使用するのに対し、Denyhostsはtcpwrappersを使用することです。他の人は以前にこの違いに言及しましたが、言及する価値があるいくつかの副次的注意事項があります。
iptablesは、効率的にブロックできるIPアドレスの数に制限があります。これが、Fail2banにブロックリストを共有するメカニズムがない理由の1つです。
別の効果は、iptablesがnftablesに置き換えられると、Fail2banはおそらく動作を停止するか、書き換える必要があることです。 Denyhostsはおそらく機能し続けるでしょう。
したがって、どちらにも長所と短所があります。私は両方好き;私は通常、SSHのみを保護する必要があるため、Denyhostsを使用しています。ブロックリストを共有するのが好きです。
Fail2Banについて注意すべき点の1つは、DenyHostsよりも約10MB多いメモリを使用しているように見えることです。したがって、128MBのVPSを使用している場合は、それを調べてみてください。また、すぐに使えるfail2banはSSHでのみセットアップされます。つまり、構成を変更することなく、DenyHostsは少ないメモリで同じことを行います。
denyhostsはssh用です。 fail2banはより包括的です（HTTP、FTPなど）。どちらも舞台裏でiptablesを使用しています。
面倒なiptablesやfail2banの設定をいじる代わりに、オープンコミュニティにすべての作業を任せて、代わりにCSF/LFDを使用してみませんか？言及されている他のすべてのオプションよりも強くお勧めします。サーバーで何ができるかについては http://configserver.com/cp/csf.html を参照してください。 CSFはコントロールパネルを必要とせず、シェルでそれを実行したくない人のために、シンプルなUI自体を提供します。そして、それは多くの安定した信頼できる非常駐Perlスクリプトです。
fail2banには、成功したsshログインを認識し、失敗の数をリセットするメカニズムがないようです。
Sshdの標準フィルター（少なくとも私のdebianインストールでは）は、サーバーが拒否したクライアントが提示する各sshキーの失敗カウントを記録します。一部のユーザーは、ログインのたびに多くのキーを提示し、いくつかのキーを通過した後でログインが成功したにもかかわらず、定期的にロックアウトされます。
上記の結果として、私は現在fail2banから離れることを考えています。この点で、少なくとも、denyhostsの方が優れています。ただし、これは明らかに良いオプションではなくなり、debianの最近のバージョンではサポートされなくなりました（ https://www.chrissearle.org/2015/06/16/replacing-denyhosts-with-での議論） fail2ban-for-debian / ）
ここには良い解決策がありません。
実際、denyHostはsshdサービス以外の多くのサービスを防ぐことができると思います。その構成ファイルで-/etc/denyhosts.conf、いくつかのコード行があります：
# BLOCK_SERVICE: the service name that should be blocked in HOSTS_DENY
#
# man 5 hosts_access for details
#
# eg. sshd: 127.0.0.1 # will block sshd logins from 127.0.0.1
#
# To block all services for the offending Host:
BLOCK_SERVICE = ALL
# To block only sshd:
# BLOCK_SERVICE = sshd
したがって、BLOCK_SERVICE変数をALLにする上記のように、sshサービスを監視できます。
Denyhostsバージョン3.0：IPアドレスがログファイルに表示されるたびに、Denyhostsはhosts.denyファイルを開き、すべてを読み取ってアドレスに一致させます。毎回。メモリには何もキャッシュされません。巨大なhosts.denyファイルがあり、多くのプローブ（多くのログファイルエントリ）の影響を受ける場合、Denyhostsは、表示されるすべてのIPアドレスのhosts.denyファイルの読み取りと再読み取りを行うCPUホグになります。良くない。
Iptablesのサポートを有効にすると、DenyhostsはブロックされたIPアドレスの巨大で遅いリストを作成します。 Denyhostsは、効率的なIPマップを作成するためにipsetまたはnftablesを使用しません。