これをここに投稿するか、セキュリティSEに投稿するか考えましたが、これは暗号化に関する質問ではなく、Linuxユーザー/権限に関する質問なので、Unix SEに投稿することにしました。私のGoogle検索能力が弱いのかもしれませんが、これまでに見つけたのは
- 具体的な例を示さずに、それが「悪い習慣」または「好ましくない」という非常に一般的な答えを言う、または
- パスワードを持たないユーザーがルートアクセス権を持っていると想定するか、または可能なすべての保護を放棄していると想定する応答があります。
明確に言うと、私はこれを主張しているわけではなく、正当な理由を探しているのですないこれをやりたいのですが、単に「それは悪い」というのではなく、具体的な理由を見つけたいと思います。 :-)
さて、その前に、そもそも私がこのことについて考えるきっかけとなった例を挙げてみましょう。
例えば、アカウントに強力なパスワードを設定するホームシステムの構築を検討しているとしますroot。さらに、非ルートアカウント fredあれはない管理者グループwheel（またはsudoersDebian / Ubuntu）で。このシステムでは、起動プロセス中にロックが解除される別のLUKS暗号化パーティションも用意します/home。つまり、パスワードするGRUBとログインマネージャの間ではまだ入力されますが、ログインマネージャは自動ログインに設定されています。これに加えて、次のように設定します（ルートから）password -f -u fred：強制ロック解除のパスワードfred（実質的にはfred空のパスワードになります）。
このような状況では、どのようなセキュリティ上の問題が発生すると考えられますか? これを実行したくないのには、何らかの正当な理由があるはずです。しかしのみ今のところ思い浮かぶのは:
- LUKSパーティションはスクリーンセーバーロックがトリガーされても閉じられません（少なくともCinnamonでは閉じられず、はトリガーに設定されています)。したがって、誰かが私の家に侵入し、
fredすでにログインしていた場合、座ってモニターをオンにして、fredアクセスできるものすべてを調べることができます。ただし、最初に PC を取り外したり、再起動したり、持ち去ったりしない限り (つまり、LUKS が再度ロックされない限り)。また、十分に努力すれば、スクリーンセーバーがトリガーされたときにスクリプトを呼び出し、そのスクリプトから LUKS をロックする方法を見つけて、この穴を塞ぐことができるのではないかと考えています (または、kde/xfce/gnome などにはすでにこれに対処する方法があるのでしょうか?)。
たとえ強力なパスワードを持っていたとしてもfred、管理者でなければソフトウェアをインストールしたりシステム設定を変更したりすることはできません。また、確かなことはわかりませんが、ブラウザやWineによるファイルへのアクセスはどちらの方法でも変更されないと思います。fred したパスワードをお持ちですか?
編集: 重要ではないと思いますが、ディストリビューションは Fedora (SELinux がオン) ですが、別のディストリビューション (または SELinux なし) に関して回答する方が快適であれば、それでも構いません。
編集＃2：ssh/についてsamba。私は通常、/media/sdb1/sharedSambaの共有や何と呼ばれているかに関係なく、フォルダーのようなものを設定します$HOME。自宅のような小さなユーザー設定では、これはかなり簡単に設定できます（もちろん、職場環境やすべてのユーザーがお互いを信頼していない環境では、これを行いません）。ただし、私は常に別のパスワードで保護されたSambaユーザーアカウント（ログインするユーザーと同じではありません）を使用し、設定を強化するためのいくつかのガイドに従っていますsmb.conf。この設定に欠陥が見つかった場合は、ログインアカウントに空のパスワードを使用して仮想シナリオ/設定を攻撃するのに有効であると見なしますfred（Sambaアカウントのパスワードはないただし空白です)。
についてはssh、デフォルトでは空のパスワードは拒否されることを確認したいと思います。全てアカウント（ だけではないroot）で。そうでない場合は、FelixJN の回答を有効と見なします。それ以外の場合は、 と同様にsamba、通常と同じセットアップ、つまりデフォルト構成の強化バージョンを使用します。これについて多くの設定を変更したことは覚えていないので、通常変更する設定を正確に見つけて、ここに含めてみます。ポート番号を変更することはわかっていますが、これはあまり重要ではありません。
拒否を確認すると、LM19 では (force) フラグをサポートしていないようで、奇妙なことに fedora では空のパスワードを持つ非 root ユーザーしか作成できないsshことに驚きました。LM19 ボックスから fedora にしようとしたところ、拒否されました。passwd-fssh
$ ssh -p 2468 fred@fedora-testbox
fred@fedora-testbox's password:
Permission denied, please try again.
fred@fedora-testbox's password:
Permission denied, please try again.
ポート以外にも、許容可能な最小の暗号/MAC/KexAlgorithms を増やし、LoginGraceTime/ MaxAuthTries/を減らしMaxSessions、PermitRootLogin no/ UsePAM yes/を設定したようですChallengeResponseAuthentication no。PermitEmptyPasswordsデフォルトは「いいえ」だったようですしかし私は明確にそう言いました。
答え1
私が考えられる最も大きな実際的な理由は、一部のネットワーク ソフトウェアによって、誰かがパスワードなしでリモートからマシンにログインできる可能性があることです。リスクは、あなたが知っているソフトウェアではなく、あなたが考えていなかったソフトウェアにあります。おそらく、ディストリビューションにパッケージ化されたソフトウェアです。
パスワードなしのユーザーの場合、マシン上のネットワークに接続されたすべてのサービスをチェックして、パスワードなしのリモート ログインが許可されるかどうかを確認する必要があります。
一般的なセキュリティ原則は、誰でも入れるようにするのではなく、全員を締め出すことで物事を「失敗」させることです。パスワードのないユーザーがいる場合、間違いや単純な見落としによってどこかのバックドアがロック解除される可能性が高くなります。
一例としては、電子メールサーバーが挙げられます。パブリックIPv4アドレスを持つマシンがあれば、意思SMTP へのログインは毎週、あるいは毎日試行されることもあります。ハッカーは脆弱なマシンを探すために、すべての IPv4 アドレスを順に調べます (アドレスは 40 億個しかありません)。
SSH も同様です。OpenSSH はパスワードなし (認証なし) のログイン試行を拒否するように設定されているため、おそらく安全です。しかし、私は毎日、空のパスワードを持つユーザー名を見つけようとするハッカーの試みを何度か目にしています。彼らは、運が良ければよいと期待して、何千もの一般的なユーザー名を順番に試しているだけです。
答え2
一般的に、次のような側面を考慮します。
- リモートアクセス：
アクティブなどのリモート アクセス オプションがある場合は、ssh明らかな理由から、これはオープン ドアとなります。その場合は、ポイント 2 と 3 が特に適用されます。
- データのプライバシーとセキュリティ:
あなたのユーザーは、権限のないユーザーには公開すべきではない情報を公開しており、もちろんあなたのデータは誰かによって削除される可能性があります。破壊的な人もいるのです。
- システムセキュリティ:
もちろん、公式にはユーザーに管理者権限はありませんが、ハッキングできないシステムはありません。ユーザーとしてアクセスできるようになると、マルウェアをアップロードしたり、セキュリティホールを悪用したり、プログラムをローカルでコンパイルしてシステムに侵入したりするのを誰も止めることはできません...
それは、誰かの邪魔にどれだけの石を置きたいかという問題です。
では、自動ログインを使用して少なくともこれらのリスクの一部を回避し、物理的なアクセスの必要性を最大限に高めることができるのに、なぜパスワードを使用しないユーザーを設定するのかという疑問が生じます。