リモートルートログイン
サーバーを保護するために最初に行うことの1つは、リモートrootログインを禁止することです。
パスワードはかなり弱いです。 sshキーまたは他のパスワードなしの方法でのみrootログインを許可することを人々はどう思いますか。
どの方法が最適ですか？リスクを冒さない方がいいですか？セカンダリアカウントでSSH接続し、su -を使用すると、本当にセキュリティが追加されますか？
Serverfault.comのユーザーはどのようにしてリモートサーバーのrootにアクセスしますか？
ほとんどの場合、リモートルートログインを実際に無効にしてもほとんどメリットはありません。これは、管理者が自分のアカウントを介してログインし、必要に応じてルートにsuするというポリシーを適用するのにわずかに役立ちます（または、ポリシーによってはSudoをsudoshと一緒に使用することもできます）。 。
非常に長くて面倒なルートパスワードを作成することは（パスワードに古いDES + 12ビットソルトハッシュをまだ使用していない限り有効です）、そのようなポリシーを適用するのとほぼ同じくらい効果的です。
私がよく知っているサイトの1つには、ホストごとに一意のパスワードがランダムに生成され、データベースに保存され、システムにプッシュされるシステムがありました。管理者は、通常のアカウントでsshを使用し、ほとんどの操作でSudoを使用する必要がありました。ただし、ルートパスワードには、SSLベースの内部Webサービスを介してアクセスできました（さらに、RSA SecurIDトークンとPINが必要でした）。ルートパスワードを取得するには、正当化（通常はRemedy（TM）チケット番号へのリンク）を入力し、定期的に監査される場所にアクセスする必要がありました。ルートパスワードを直接使用するいくつかの許容できる理由の1つは、ブートプロセス中にシステムがfsckで停止された場合でした...そしてsuloginは順番に実際のルートパスワードを必要としていましたファイルシステムのチェックおよび修復プロセスを手動で実行します。 （これの代替方法についていくつかの議論がありました--- Linuxにとっては比較的簡単ですが、手順を拡張して多くのレガシーHP-UX、AIX、および古いSunOSおよびSolarisシステムを説明しようとするとはるかに困難になりますその環境ではまだ本番環境でした）。
ルートパスワードが必要な場合があります---または少なくとも利用可能な最善の代替手段です。予想できる種類の脅威に対して十分に堅牢にしながら、利用可能な状態を維持することが、一般的に最善の戦略です。
私が知っている別のサイトは、分散型アカウント管理に対してかなりエレガントなアプローチを採用しています。それらには、通常のパッケージ管理手順と自動化インフラストラクチャを使用してシステムにインストールされるuser- *およびSudo- *パッケージ（RPMと考えてください）があります。彼らの場合、Sudo- *パッケージは対応するuser- *パッケージに依存しています。これは、ローカライズされたアカウント（すべてのアカウントは管理者、開発者、サポートスタッフ、または「ヘッドレス」アカウント）を持つマシンのクラスターを作成でき、LDAP/NISまたはその他のネットワークIDおよび認証サービスへの依存を排除できるため便利です。 （これにより、システム間の結合が減少し、システムが大幅に堅牢になります）。
そのアプローチについて私が気に入っているのは、柔軟性が得られることです。 Sudoアクセス権を持つユーザーは誰でも、通常のユーザーまたは別のSudoユーザーアカウントを追加するコマンドを発行できます。したがって、チケットを作成している場合、すでにシステムにアクセスできる人なら誰でも簡単にアクセスできます。一部の中央データベースのアクセス制御リストに私を追加するチケットが、一元化された承認プロセスを経て、最終的に問題のシステムに変更を伝播する間、遅延はありません。システム上の許可されたSudo- erは誰でも、私にアクセスを許可し、後で私を削除することができます。 （はい、私が悪で、彼らが私をゲームにした場合はSudoアクセスを維持するために悪意を持って変更する可能性があります...実際、通常のユーザーと同じように、そのような削除後もアクセスを維持するためにできることがいくつかあります。それは彼らが心配している脅威ではありません。私のアクセスはまだ全体的に比較的少数のシステムに制限されているので、侵害されたアカウントの影響は私が見たほとんどの同様のスキームよりもさらに制限されています。
リモートルートアクセスを無効にすると、リモートの攻撃者が直接ルートを取得するのを防ぐことができます。別のアカウントを破り、マシンにアクセスしてから、ルートへのアクセスを試みる必要があります。それは余分なステップです。
通常、rootはリモートアクセスに対して無効になっています。 SUはうまく機能します。何かが本当に壊れた場合、それを修正するためにボックスに直接アクセスできます。
より厳密にしたい場合は、rootを完全に無効にするだけで、Sudoがその目的になります。繰り返しますが、そのアプローチでは、シングルユーザーモード（Ubuntu）にドロップすることでrootアクセスを取得できます。ただし、ドキュメントによると、パッチを適用したinitを使用したと思います。
さらに、端末が開いたままになっている場合やPCも開いている場合に、アイドル状態のユーザーをキックオフするようにアイドル状態に設定できます。すべてのユーザーにキーの使用を強制することはできますが、キーの管理が難しい場合があります。
ブレークグラスタイプのシステムとしての単一のパススルーロギングホストも、追加の保護層と監査証跡を強制しました。
コンソールでのみルートアクセスを許可するようにシステムを設定することをお勧めします。
それ以外の場合は、パスワードオプションを指定してSudoを使用し、選択したユーザーにpriv'dコマンドへのアクセスを許可します。ところで、Sudoは、必要に応じてユーザーアカウントを特定のコマンドに制限するように設計できることを理解してください。須藤は、使用されたことを示す「マーク」をシステムログに残します。 rootパスワードが開示されないため、sudoはsuよりも優れています。したがって、rootパスワードを変更することができ、Sudoを使用するユーザーは賢明ではありません。
Sudoを使用してpriv'dコマンドを取得するには、環境に応じた頻度でパスワードを定期的に強制的に変更する必要があります。
ルートを許可しない
パスワードなしでキーのみを介したアクセスを許可するようにシステムを設定します
次に、rootアカウントを介して変更を行うことを許可されたユーザーにSudoを設定します