web-dev-qa-db-ja.com

2日間でauth.logでrootパスワードの試行が19,000回失敗しましたか？

ログインの問題をデバッグしていて、たまたま自分の/var/log/auth.logでrootパスワードの試行が失敗したことに気づきました。これはVPS Linodeです。

私は過去2日間で19Kの試みを見つけた。

Sshdを別のポートに移動することになっていることはわかっていますが、覚えて使用するのは面倒なようで、多くのスクリプトを更新する必要があります。その上、攻撃者は新しいポートを見つけるために単にポートスキャンすることはできないのですか？

Rootには非常に強力なパスワードが設定されているので、あまり心配する必要はありません。

そして、私はそれが1分あたりわずか6だと思います...それで、おそらくパフォーマンスの問題ではありません。

しかし、それは理想的ではないようです。

それをブロックまたは防止する方法についての考えはありますか？

IPアドレスのかなり小さいリストから来ているようです...多分私はそれらをブロックできますか？いくつか確認したところ、中国にあるようです。

別のオプションは、rootログインを無効にし、一意のユーザー名でSudoユーザーを設定することです。しかし、それがこの特定の問題に役立つとは思いません---人々はまだrootとしてsshを試みることができます...

更新：デフォルト設定でapt-get install fail2banを実行した後、auth.logで失敗したroot試行の数が6〜8倍減少しました。

root@localhost:/var/log# grep "Failed password for root" auth.log | wc
    21301  327094 2261733
root@localhost:/var/log# grep "May  1.*Failed password for root" auth.log | wc
    6217   95973  664165
root@localhost:/var/log# grep "May  2.*Failed password for root" auth.log | wc
    8370  127280  880779
root@localhost:/var/log# grep "May  3.*Failed password for root" auth.log | wc
    1030   16250  111837

また、次のようにして、ルートsshパスワード認証を排除し、ルートのみのキーベースのログインに切り替えました： https://unix.stackexchange.com/questions/99307/permit-root-to-login-via -ssh-only-with-key-based-authentication

ただし、これによって、失敗したパスワードエントリがauth.logに表示されるのを防ぐことはできません。これは、たとえパスワードを知っていても、通過できないことを意味します。したがって、fail2banはそれらのログエントリを削減し、rootのキーベースのsshは実際のセキュリティを提供します。

最後に、提案したように、ログエントリを完全に排除するために、ポート22にIPホワイトリストを実装しました。参考までに、これはUbuntuでufwを使用して次のように実行できます。

apt-get install ufw
ufw allow from 127.198.4.3 to any port 22
ufw --force enable

ここでは--forceを使用しています。これは、新しいノードを起動するときに、非対話的にスクリプトでこれを実行しているためです。

ただし、IPが変更されるたびにLinodeのWebベースのLishコンソールを操作することなく、動的IPからのアクセスに対処するために、ハイブリッドアプローチを使用しています。

メインドメインをホストするメインサーバーがあり、他のノードはサブドメインのサブサーバーとして必要に応じて起動されます。メインサーバーには、サブサーバーへのSSH接続に使用されるプライベートキーが格納されています。また、sshのホワイトリストに登録されているIPです。

ただし、メインサーバーはsshキーもIPホワイトリストも使用しません。キーファイルを持っていない場合や、キーファイルのインストールを信頼できない場所からでも、緊急時にどこからでもアクセスできるようにしたいと考えています。パスワードアクセスのようなものが必要ですが、キーロギングまたはsshが侵害された環境では安全です。

私が長年使用してきたその解決策は、YubiKey USBデバイスを使用したハードウェアベースの2要素認証と、メインサーバーにインストールされたYubico PAMモジュールです。

したがって、攻撃者がメインサーバーへのルートパスワードを持っている場合でも、私のYubiKeyなしでは侵入できません。そして、それは私と一緒に持ち運ぶのは簡単です。世界で最も汚いインターネットカフェからサーバー上のルートに安全にアクセスできます。

メインサーバーに到達した後、パスワードを入力せずに任意のサブサーバーにSSHで接続できます。

したがって、auth.logエントリを削減するために、メインサーバーでfail2banが必要です。 IPホワイトリストが問題を処理するので、サブサーバーでは結局必要ありません。

linuxsshauthentication
2
Jason Rohrer

ブルートフォース攻撃から特定のIP範囲をブロックしようとすることは、問題に取り組むための理想的な方法ではありません。多くのボットネットとサーバーがインターネットを常にスキャンし、サーバーとデバイスを危険にさらそうとしています。トラフィックをブロックしようとすることは非常に非効率であるため、最善策は、トラフィックを軽減するか、まとめて回避することです。

表示される接続数を軽減する1つの方法は、SSHポートを変更することです。ほとんどの攻撃者は、攻撃的なホストに対してショットガンアプローチを採用しているため、非標準の代替ポートを選択する限り、それが標的型攻撃でない限り、SSHの試行は多くありません。インターネット上のすべてのポートをスキャンするには時間がかかるため、これは最善の方法ではありませんが、一部の攻撃を軽減する方法と見なすことができます。

別の緩和方法は、Fail2Banのようなものを設定して、複数回認証に失敗したIPを自動的にブラックリストに登録することです。これにより、一部の攻撃を緩和できますが、ブルートフォース攻撃のほとんどが分散ホストから行われるため、最近はあまり効果的ではありません。

SSHセキュリティを処理する最良の方法は、サービス自体へのアクセスを制限することです。これは、SSHポートへのアクセスが許可されているIPをホワイトリストに登録し、キーベースの認証を設定してからパスワード認証を無効にすることで実行できます。攻撃者がSSHポートに到達できないか、パスワードを試す機会がまったくない場合、ブルートフォース攻撃の心配はほとんどありません。

3
Jenos

長いrootパスワードは当てになりません。 18文字はあまり長くありません。特に、ほとんどの場合、いくつかの記号と数字を含む単語の場合はそうです。

一般に、サーバー（特にパブリックサーバー）でパスワードを使用してrootログインを許可することはお勧めできません。いくつかの理由があります。ユーザー名を推測するのは簡単であり、問​​題が多すぎて、人がたくさんいるからです。そこにスクリプトがあります。

すべてのユーザーを鍵ベースの認証のみに切り替えることも、悪い考えではありません。これにより、ブルートフォース攻撃の脅威が大幅に排除されます。

0
dogoncouch