web-dev-qa-db-ja.com

潜在的なハイジャックされたSSHセッションとSSHのベストプラクティス

私は今少しおかしくなっています。最近委託したリモートサーバーにSSH接続しています。これをrootとして実行します。 fail2banをインストールし、大量の禁止IPをログに記録しました。

前回ログインしたとき、端末が本当に遅いのに気づき、インターネット接続がダウンしました。約5分後にバックアップを購入したとき、サーバーに再度ログインして「who」を実行し、2人のrootユーザーがログインしていることに気付きました。接続が最後のセッションからプロセスを終了した場合は、サーバーで停止しましたか?

最初に切断されたとき、接続は「書き込み失敗:パイプの切断」で終了しました。他のrootとのbashセッションを終了しました。 sshのセキュリティについてよく知りませんが、セッションがハイジャックされる可能性はありますか?これをチェックする方法はありますか? ssh経由でログインし続ける必要がありますが、どのような予防策を講じる必要がありますか?私が何らかの方法でプロキシを経由してサーバーに到達した場合(中間の攻撃の男のように)、彼らは私のsshセッションをハイジャックできますか?

14
MarMan29

Rootログインは、おそらくあなたがかつて行っていたシェルセッションをぶら下げています。また、サーバーは、dDOSを取得しており、ログインを試みたすべてのユーザーがそれを攻撃しています。

SSHをロックダウンします。 rootログインを許可しないでください。このマシンをブルートフォースで攻撃しようとするリクエストは、すぐに失敗します(使用するリソースがはるかに少なくなります)。通常のユーザーとしてログインし、Sudoを介して権限を昇格します。これは、とにかく行うべき習慣です。また、SSHログインをクライアントIPのリストに制限して、悪意のあるマシンがログインを試行できないようにします。

ユーザーのログインには、パスワードの代わりにSSHキーを使用します。それらは扱いやすく、誤って間違った場所に秘密鍵を渡した場合に備えて、パスワードで保護することができます(それらを交換して古いものを無効にする時間を与えます)。コメントで@EEAAが述べたように、パスワードとキーの両方ではなくキーのみを使用するようにクライアントを制限する場合は、パスワードベースの認証も無効にする必要があります。

モンゴルの氏族があなたの城壁を荒らし続けている場合は、SSHを22ではなく別の高いポート(@AustinBurkeが指摘しているように、1024未満)に移動します。これにより、このポートのトラフィックが減少します。はあなたにとって問題です(そして、ほとんどのボットはあまり優雅ではないため、22でのみ試行します)。ポート22を試したり、マシンをスキャンしてSSHでリッスンしているポートを確認したりすることを妨げるものではなく、ほとんどの場合、不必要な不便さです。しかし、それは役立つかもしれません。

他の人がより多くのヒントを提供できるかもしれませんが、これらは一般に公開されているSSHサーバーのかなり一般的なセキュリティ対策です。

40
Spooler