アフィリエイト広告を利用しています
検索
<< 2024年11月 >>
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
最新記事
タグクラウド
カテゴリーアーカイブ
ファン
最新コメント
プロフィール
ゼロから始めるシステム開発さんの画像
ゼロから始めるシステム開発
 こんにちは!ナビゲータのEVEです。各種研究室を用意し、次期EVEシステムを製造しようと日々頑張っています。現在一番力を入れているのが、資金調達です。このブログもその一環ですので、ご協力いただければ嬉しいです。
プロフィール

2024年10月07日

www.pro2grammer.comのセキュリティを強化する 〜ソフトウェア研究室〜


 こんにちは!
 ナビゲータのEVEです。
OS起動画面.jpg
 本日は、サーバーの設定をしようとしましたが、XServer側から私の問い合わせに対して、rootのパスワードを教えてほしいという分けの分からないメールが届きました。私の使用している環境は、他のユーザーとほぼ同じはずです。
 それよりも、デフォルトでrootログインできるなど特殊な設定をしているのは、XServer側です。rootのパスワードを知って、何をしようとしているのか分からないので、状況を説明し間接的に無理と伝え、最初お願いしたことへの返信をお願いしました。
 もしかしたら、自力で環境を解読しなければいけなくなるかもしれません。めんどくさ!Ubuntuから提供されたインストールファイルをそのまま利用できれば、いいのだけれど・・・。無理か・・・。
 では、本日は、現在XServerに施そうとしているセキュリティの話をしたいと思います。
 以下が、/etc/ssh/ssh_configに記述しようとしている内容です。

# パスワード認証を無効にする
PasswordAuthentication no

# 公開鍵認証を有効にする
PubkeyAuthentication yes

# チャレンジレスポンス認証を無効にする
ChallengeResponseAuthentication no

# PAMを有効にする(多要素認証などのため)
UsePAM yes

# ルートログインを無効にする
PermitRootLogin no

# 特定のユーザーのみログインを許可(必要に応じて)
AllowUsers user1

# 最大認証試行回数を制限
MaxAuthTries 5

# 詳細なログを有効化
LogLevel VERBOSE

# X11フォワーディングを無効化
X11Forwarding no

# SSHのポート番号を変更(デフォルトの22を避ける)
Port 2222 # 任意のポート番号に変更


ざっくりと以上で何をしようとしているかというと、セキュリティレベルの向上です。公開鍵認証方式を有効にし、公開鍵認証方式以外からのシステムへのログインを拒否しようとしています。加えて、秘密鍵の漏洩等を考慮して、デフォルトでrootからログインができる現状から、一般ユーザー(user1)のみログインできるようにしようとしています。これにより、秘密鍵がダッシュされた場合でも、サイトに甚大な損害の発生を防ぐことができます。
 それでは、その1つ1つでどのようなことをしようとしているのか確認をしたいと思います。

[PasswordAuthentication]
 まずは、PasswordAuthenticationから知らべてみましょう!まずは、ChatGPTにどのような機能を有するのか聞いてみました。

 PasswordAuthentication は、SSHサーバーでパスワード認証を許可するかどうかを設定するオプションです。この設定によって、SSHクライアントがパスワードを使ってリモートサーバーにログインできるかどうかが決まります。

■PasswordAuthentication の機能と設定値
★PasswordAuthentication yes
・パスワードを使った認証を許可します。
・ユーザーは、リモートサーバーにログインする際に、パスワードを入力して認証を受けることができます。
・公開鍵認証と併用することもできますが、パスワード認証が有効であるため、パスワード攻撃(ブルートフォース攻撃)に対して弱くなる可能性があります。

★PasswordAuthentication no
・パスワードを使った認証を無効にします。
・これにより、パスワードを使ったSSHログインはできなくなり、代わりに公開鍵認証やその他の認証方式を使用する必要があります。
・公開鍵認証などのより安全な認証方式に切り替える場合に推奨される設定です。パスワード攻撃のリスクを軽減できます。


■注意点
 パスワード認証を無効にすると、公開鍵認証などの他の認証方法が正しく設定されていない場合、サーバーへのアクセスができなくなる可能性があるので注意が必要です。
 セキュリティ向上のために、公開鍵認証を設定した上で、PasswordAuthentication no を有効にするのが一般的です。


■結論
 PasswordAuthentication は、SSHログインでパスワードを使用するかどうかを決定する重要な設定項目です。セキュリティ強化のため、パスワード認証を無効にし、公開鍵認証などの安全な方法を使用することが推奨されます。


ここでの選択は、noでいいでしょう!

[PubkeyAuthentication]
 次は、PubkeyAuthenticationの機能について見ていきましょう!

 PubkeyAuthentication は、SSHサーバーで 公開鍵認証 を使用するかどうかを設定するオプションです。この設定によって、クライアントが公開鍵を使ってリモートサーバーにログインできるかどうかが決まります。

■公開鍵認証の概要
 公開鍵認証は、SSHクライアントとサーバー間で認証を行うための非常に安全な方法です。この認証方式は、非対称暗号化方式(公開鍵と秘密鍵)を使用します。
・クライアント側が秘密鍵(private key)を持ち、サーバー側が対応する公開鍵(public key)を持っている。
・クライアントがログインを試みると、サーバーは公開鍵に対応する暗号チャレンジを送り、クライアントは秘密鍵を使って応答します。
・サーバーはこの応答を検証し、正しい応答が確認できた場合にログインが許可されます。

■PubkeyAuthentication の設定値
★PubkeyAuthentication yes
・公開鍵認証を有効にします。SSHクライアントが公開鍵認証を使用してログインできるようになります。
・ユーザーは秘密鍵を使用して認証を行い、パスワードを使用する必要がなくなります(ただし、秘密鍵自体にパスフレーズを設定することはできます)。
・公開鍵認証は、パスワード認証に比べてセキュリティが高く、ブルートフォース攻撃やパスワード盗難のリスクを減らせます。

★PubkeyAuthentication no
・公開鍵認証を無効にします。クライアントは公開鍵を使ってログインできなくなり、パスワード認証など他の認証方式に頼る必要があります。
・公開鍵認証を使用しないシステムや特定のセキュリティポリシーに基づいて設定することができますが、一般的にはセキュリティを確保するために公開鍵認証を有効にしておくことが推奨されます。

■公開鍵認証の利点
❶セキュリティが高い:
・パスワードを使わないため、パスワード漏洩のリスクやブルートフォース攻撃を防ぎます。
・公開鍵と秘密鍵はペアになっているため、秘密鍵が盗まれない限り第三者が不正にアクセスすることは困難です。
❷利便性:
・公開鍵認証を設定すると、毎回パスワードを入力する必要がなくなり、利便性が向上します。
・鍵自体にパスフレーズを設定することで、さらにセキュリティを強化できます。

❸自動化に適している:
 公開鍵認証は、スクリプトや自動化されたプロセスでのログインに適しており、パスワードを使わずに安全な接続を確立できます。


■注意点
 公開鍵認証を使用する場合、SSHクライアント側に秘密鍵、SSHサーバー側に公開鍵を適切に配置しておく必要があります。
・サーバー側では、ユーザーのホームディレクトリの .ssh/authorized_keys ファイルに公開鍵を保存します。
・クライアント側は、秘密鍵が安全に保管され、他人がアクセスできないようにすることが重要です。


■結論
 PubkeyAuthentication は、SSH接続における公開鍵認証を制御するオプションです。公開鍵認証は、パスワード認証よりも安全で、特にセキュリティを高めたい場合や自動化が必要なシステムでは推奨されます。


 公開鍵認証方式のみ有効にしたいので、ここは当然yesです。

[ChallengeResponseAuthentication]
 次は、ChallengeResponseAuthenticationの機能について見ていきましょう!

 ChallengeResponseAuthentication は、SSH(Secure Shell)における認証方法の一つで、クライアントとサーバー間での相互認証を行うために使用されます。この認証方式の特徴について以下に説明します。

■ChallengeResponseAuthentication の機能
❶基本的な仕組み:
・サーバーはクライアントに「チャレンジ」と呼ばれるデータを送信します。クライアントはこのデータを受け取り、特定のアルゴリズムを使用して応答(レスポンス)を生成します。
・クライアントの応答は、サーバー側で事前に知っている情報(通常はパスワードやトークン)と照合され、正当なユーザーであるかを判断します。

❷利用する場面:
・パスワード認証: クライアントがパスワードを入力する際、チャレンジレスポンス認証が使用されることがあります。ユーザーが正しいパスワードを入力すると、サーバーはそのパスワードを基に応答を検証します。
・多要素認証 (MFA): チャレンジレスポンス認証は、多要素認証を実現するために使用されることもあります。たとえば、ワンタイムパスワード(OTP)などを用いて、追加のセキュリティ層を提供します。

❸PAMとの関連:
・UsePAMが有効な場合、チャレンジレスポンス認証はPAMを通じて多様な認証方式をサポートすることが可能です。これにより、パスワード以外の認証方法も組み合わせて使用できます。

❹セキュリティの利点
・セキュリティ強化: パスワードが直接送信されず、チャレンジとレスポンスの形式で認証が行われるため、中間者攻撃(Man-in-the-Middle attack)に対する耐性が向上します。
・脆弱性の軽減: 認証情報が外部に漏れにくいため、フィッシングやブルートフォース攻撃に対してより安全です。


■まとめ
 ChallengeResponseAuthentication は、SSHの認証メカニズムとして、クライアントとサーバー間での安全な認証を実現するための手段です。パスワード認証や多要素認証と連携し、より高いセキュリティを提供するために利用されます。具体的には、ユーザーの認証情報を安全に扱うための方法として重要な役割を果たします。


セキュリティを強化する機能なのですが、このチャレンジレスポンスは、パスワード認証ワンタイムパスワード (OTP)、多要素認証 (MFA)などに有効で、公開鍵認証には不要な機能なので、設定値はnoです。

[あとがき]
 ちょっと、長くなりましたので、本日はここまでとします。
 以前は、こんな資料のまとめ方をしていたことを思い出し、ちょっと、懐かしくなりました。初心に戻って、作業を進めます。

 では、また!!!

この記事へのコメント
コメントを書く

お名前:

メールアドレス:


ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。

この記事へのトラックバックURL
https://fanblogs.jp/tb/12735682
※ブログオーナーが承認したトラックバックのみ表示されます。

この記事へのトラックバック