クラウドサーバーでパスワードなしの「sudo」を設定しても問題ありませんか?

解決策 1:

<ブロック引用>

キーを介してサーバーにアクセスするというアイデアが気に入っているので、ボックスに ssh するたびにパスワードを入力する必要はありません。ユーザー (root ではない) のパスワード (passwd -l ユーザー名) をロックすることもできるため、ログに記録することはできません。キーなしで...サーバー上のユーザーアカウントに対してこれを行うことをお勧めしますか?

パスワードベースのログインを間違った方法で無効にしようとしています。ユーザーのアカウントをロックする代わりに、PasswordAuthentication no を設定しますあなたの /etc/ssh/sshd_config で .

この設定により、ssh のパスワード認証は無効になりますが、sudo のパスワードは引き続き使用できます。

唯一 NOPASSWD に設定することをお勧めします in sudo は、プロセスが sudo を介してプログラムでコマンドを実行できる必要があるサービスアカウント用です。そのような状況では、特定のみを明示的にホワイトリストに登録してください。アカウントが実行する必要があるコマンド。インタラクティブなアカウントの場合、常にパスワードを有効のままにしてください。

フォローアップの質問への回答:

<ブロック引用>

しかし、/etc/ssh/sshd_config でパスワード認証を無効にして、ログインにキーが必要な場合は、sudo だけに入力しやすい単純なパスワードを使用できますか?それは有効な戦略ですか?

それは正解です。比較的強力なローカルアカウントのパスワードを使用することをお勧めしますが、途方もなく強力ではありません。 ~8 文字、ランダムに生成されたもので十分です。

<ブロック引用>

ssh 経由で root としてログインするためのキーも持っている場合、誰かが私のコンピューターにアクセスして私のキーを盗んだ場合 (ただし、OS のキーリングパスワードによって保護されています!)、root アカウントに直接アクセスできる可能性があります。 sudo パスをバイパスします。

ssh による root アクセスは無効にする必要があります。限目。 PermitRootLogin no を設定あなたの sshd_config で .

<ブロック引用>

では、root アカウントにアクセスするためのポリシーはどうあるべきでしょうか?

サーバーのコンソールへの帯域外アクセスを取得する手段を常に用意しておく必要があります。専用ハードウェアのベンダーと同様に、いくつかの VPS ベンダーがこれを提供しています。プロバイダーが実際のコンソールアクセス (たとえば、EC2) を許可していない場合でも、通常は、この回答で概説するようなプロセスを使用してアクセスを復元できます。

解決策 2:

通常、NOPASSWORD の使用を制限します自動化されたプロセスによって実行されるコマンドに。これらのコマンド用のサービスアカウントを用意し、sudo の使用を必要なコマンドに制限することをお勧めします。

NOPASSWORD を許可一般的なコマンドの場合、ユーザー ID にアクセスできるすべてのユーザーが任意のコマンドを実行できます。これは資格情報が侵害されたことが原因である可能性がありますが、あなたが席を離れたときに誰かがあなたの机に座っているという単純なものである可能性もあります。

パスワードを頻繁に入力する必要はありません。パスワードを入力したら、あまり長く待たなければ、いくつかのコマンドを実行できます。タイムアウトは構成可能です。

解決策 3:

ログインと sudo の両方に SSH 認証を使用するという、両方の長所を活用できます。 pam_ssh_agent_auth モジュールを統合すると、sudo 時にパスワードを入力せずに SSH キーを使用して認証できます。

私はこれを5年以上本番環境で使用しています。

構成するには、PAM モジュールをインストールしてから、/etc/pam.d/sudo に行を追加します。またはあなたのシステムの同等物:

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys

これを行う場合は、必ずコンピュータ上のキーをパスフレーズで保護してください。そうすれば、誰かがコンピュータに侵入してキーを盗む必要があります。アカウントにアクセスできる場合は、ロックが解除されている間にメモリからキーを引き出すか、パスフレーズをクラックするか、入力中にキーロガーまたはショルダーサーフィンをしている (後ろを見てください!)。

ログインに使用するのと同じ SSH キーを使用することも、sudo を実行するときにのみエージェントに追加する別のキーをセットアップすることもできます。したがって、特に注意が必要な場合は、sudo が必要な場合にのみエージェントに追加する別の SSH キーを持つ別の authorized_keys ファイルを維持できます。

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_sudo

解決策 4:

これは次の 2 つの状況でのみ使用します:

絶対に 特定のユーザーとして実行されている自動スクリプトに必要
特定の管理タスク (システムを変更するアクションを実行するものではなく、読み取り専用の管理タスク) の場合、そしてもちろん特定のユーザーの場合のみ

デフォルトでは、ほとんどの sudo 構成は、同じセッションでしばらくの間、再度要求することはありません (効果のない新しいシェルを開いた場合)。 timestamp_timeout を使用して、この動作をある程度制御できます。

パスワードレス sudo パスフレーズなしの ssh ほど危険ではありませんリモートの攻撃者が最初に侵入するにはあなたの資格情報が必要ですが、何らかの方法であなたの秘密鍵を侵害して侵入した場合 (または、物理的にあなたの近くにいて、ログインしてロックを解除したままにしておく場合)マシンから）、パスワード要求は、それらと特権アクセスとの間の貴重な追加防御です.

フォローアップ 2 について:

<ブロック引用>

ssh 経由で root としてログインするためのキーも持っている場合

まさにあなたが説明した理由から、これも避けるのが最善です。リモート接続に特権アクセスが必要な場合は、サービスアカウントを介してログインし、sudo を介してジョブを実行するのに十分な制御を与えます。もちろん、これは構成するのがより簡単なので、多くの人は気にしません (そうすれば、攻撃者が時間を費やすよりも簡単な成果がたくさんあるので、あなたに有利に働きます!)、したがって、それはセキュリティと利便性の間で古くからある妥協点 (プロのヒント:セキュリティを選択してください!)。

解決策 5:

あなたが尋ねたので、これが sudo に対処する方法に関する私の一般的なアドバイスです問題。

Sudo は、より多くのセキュリティを提供するように設計されたわけではありません (ある程度の点では可能ですが)... むしろ、システムで誰がどの権限で何を行っているかの優れた監査証跡を提供します。

適切に設定された Sudo は ALL=(ALL) ALL を使用しません設定ではなく、ユーザーが特に必要とするものに限定されたものです。たとえば、ユーザーがログインしてスタックしたサービスを再起動できるようにする必要がある場合、新しいソフトウェアをインストールしたり、サーバーをシャットダウンしたり、ファイアウォールルールを変更したりする機能はおそらく必要ありません。

sudo を使用して自分自身を root アカウントに昇格させることがよくあります。 sudo su - .彼らがそれを行うと、ルートアカウントから誰が何をしているかを見ることができなくなります (ルートは同時に複数回ログインできます)。そのため、sudo su - を無効にしたい場合があります。コマンドも。しかし、実用上の理由から、管理のために完全に root 権限を持つアカウントが必要な場合は、少なくとも誰かに sudo su - を発行してもらいます。コマンドは誰がいつ root に昇格したかをログに記録します。

ボックスを固定する方法:

SSH ポートをデフォルト以外に変更します。 これは、ポート番号を探して、侵入する (または侵入しない) まで攻撃するダムボットを回避するためです。

AllowRootLogin no を使用した SSH 経由のルートログインを許可しない sshd_config で設定します。 これにより、誰かが root アカウントにブルートフォース攻撃を仕掛けるのを防ぎます。監査上の理由とセキュリティのために、誰かがルート/管理者アカウントに直接ログインすることを決して許可しないことは、一般的には良い習慣です。 root への直接ログインを許可すると、誰がログインしたか、誰からパスワードを取得したかなどはわかりません。監査検索 (およびリセットするアカウント)

SSH を必要とするユーザーのみに SSH を許可する AllowUsers を使用設定し、SSH アクセスが必要なアカウントを明示的に指定します。これにより、デフォルトで他のすべてのアカウントが SSH からブロックされます。

visudo を介して Sudoers を編集し、ユーザーが必要とするコマンドのみを許可します。 これを行う方法については詳細なガイドがたくさんあるので、ここでは詳しく説明しません。これがスターターです:http://ubuntuforums.org/showthread.php?t=1132821

これの要点は、侵害されたアカウントがマシンを危険にさらすのを防ぐことです。すなわち。 Sally のアカウントが侵入され、Sally が sudo を使用して Web サーバーを再起動することしかできない場合、攻撃者はループで Web サーバーを再起動することを楽しんでいる可能性がありますが、少なくとも rm -rf /your/webserver/directory はできません。または、すべてのファイアウォールポートを開きます。

ボックスの動作に必要なポートのみを許可する適切なファイアウォールルールを設定します。 通常、すべてを削除して、必要なものだけを明示的に許可します。まともな iptables がたくさんあり、他のファイアウォールがオンラインで起動します。ここに私が使用するものがあります (これは基本的なスターターです):

# Generated by iptables-save v1.4.7 on Mon Mar  3 17:55:02 2014
*filter
:INPUT DROP [4528:192078]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [39845:27914520]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4254 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -m state --state NEW -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Mon Mar  3 17:55:02 2014

強力なパスワードも重要です。 リモートアクセスに SSH キーを使用する場合でも、Sudo を使用するにはパスワードが必要です。これは、sudo がセキュリティを強化できるケースです。誰かがあなたの ssh キーを盗んだとしても、sudo を使用するためにアカウントのパスワードをブルートフォースしなければならない場合でも、ボックスで重要なことを行うことはできません。パスワードは単語ではなく、パスフレーズにする必要があります。文を考えて、それを使ってください。これにより、通常、8 文字を超える長さが得られ、十分なエントロピーが提供されますが、ランダムなパスワードよりも覚えやすくなります。もちろん、適切なパスワードの実践では、機械で生成されたランダムなパスワードを使用して、ほとんどのパスフレーズやパスワードを解読する John the Ripper のようなクラッキングツールをだますように言っています。いいえ、E を 3 に変更しても機能しません。John もこれらの順列を取得します。