web-dev-qa-db-ja.com

RHEL 7（CentOS 7）セキュリティ/ ssh / sshd_configアドバイスが要求されました

私はシステム管理者ではなく、多かれ少なかれ安全なWebサーバーを作成しようとしています（LAMPベース CentOS 7 ）。
最初のCentOS7ドロップレットのセットアップに関するいくつかのチュートリアルを読み、すべてが正常に実行されるようにしました。

しかし、私が読んだ記事で読んだいくつかの基本的な概念を理解するのに苦労しており、副作用について確信が持てないという理由だけで、より資格のある人々の入力が必要です。

ご意見をお待ちしております。

シナリオ：
Digital Oceanでcloud-init（ユーザーデータ）を使用して、新しいドロップレットを作成およびプロビジョニングしています。私が理解している限り、cloud-initはsystem/rootとして実行され、rootのssh_configに固有の以下の設定を作成します。

  • そのユーザーのsshキー（ssh-authorized-keys）に沿って新しいユーザーを作成する（このシナリオでは彼をadminと呼びます）a
  • そのユーザーをグループホイールに追加し、Sudoを設定します：['ALL =（ALL）NOPASSWD：ALL']
  • / etc/ssh/sshd_configでrootログインを無効にします
  • / etc/ssh/sshd_configのAllowUsersadmin
  • passwordAuthentication no in/etc/ssh/sshd_configを設定します
  • / etc/ssh/sshd_configでPubkeyAuthenticationyesとRSAAuthenticationyesを設定します
  • firewalldの設定とその他のタスクの実行

質問：

  1. ユーザーadminとしてsshを介してドロップレットを接続した後、関連するsshd_configは空です。これは、ドロップレットが作成されてcloudconfigが実行されるときに、cloud-initがsystem/rootとして実行されるためだと思います。

    1.1rootユーザーのドロップレット作成時に行ったのと同じ設定をここで設定する必要がありますか？ 1.2もしそうなら、複数のssh_configファイルの意味は何ですか？

  2. Cloud-initログファイルを見ると、rootの公開/秘密rssキーペアが作成されていることがわかりました。
    代わりにrootユーザーに最初のsshキーを提供しないことにしたので、関連するパスワードが私に郵送されます（テスト目的のためだけに）。
    ただし、新しく作成されたユーザー管理者の/ ls -aでetc/sshを実行すると、次のように表示されます。

    . moduli sshd_config ssh_Host_dsa_key.pub ssh_Host_ecdsa_key.pub ssh_Host_rsa_key.pub .. ssh_config ssh_Host_dsa_key ssh_Host_ecdsa_key ssh_Host_rsa_key

    たとえばssh_Host_rsa_keyを見ると、rootユーザー用に作成されたものと同じsshキーが含まれています。

    2.1新しく作成したadmin（rootではない）というユーザーがsshフォルダーにrootと同じキーを保持する理由と目的は何ですか？

    2.2それは、彼をグループホイールとSudoに追加したためです：['ALL =（ALL）NOPASSWD：ALL‘]？それはお勧めですか？

    2.3別のユーザーアカウントが危険にさらされる可能性があり、必要なすべてのキーを保持している場合、sshを介したリモートログインへのrootの許可を禁止する意味は何ですか？ハッカーは非常に幸運です人？名前を推測するのが難しいユーザーを作ることだけが目的ですか？

  3. 一部のアクションにはまだSudo/root権限が必要であることを理解しました。 adminとしてログインした場合、surootを使用してrootに変更できます。

    3.1/ etc/ssh/sshd_configでrootログインを無効にしたので（つまり、ssh専用ですよね？）、作成された新しいユーザー（admin）は同じ権限で、rootに簡単に切り替えることができます。そのパスワードをより適切に保護するために何ができるか、またはセキュリティレベルを追加するTwo Factor Authなどがあるかどうかを自問しています。

    3.2。一方、管理者アカウントの制御を成功させたハッカーが、どのようにしてより良いレベルのセキュリティになるかはわかりません。ルートのsshキーを簡単に読み取り（上記の前のトピックを参照）、セキュリティレイヤーをバイパスしますか？

要するに：私は読んでいたものがとても好きでしたが、具体的には、cloud-initを使用して作成したユーザーのsshフォルダーでルートsshキー（プライベートとパブリック）を見つけた後、filesysteを調べました。何かを誤解した。

ちなみに、これは私のcloud-initスクリプトです：

#cloud-config

# log all cloud-init process output (info & errors) to a logfile
output: {all: ">> /var/log/cloud-init-output.log"}

# final_message written to log when cloud-init processes are finished
final_message: "System boot (via cloud-init) is COMPLETE, after $UPTIME seconds. Finished at $TIMESTAMP"

package_upgrade: true

users:
  - name: admin
    groups: wheel
    Sudo: ['ALL=(ALL) NOPASSWD:ALL']
    Shell: /bin/bash
    ssh-authorized-keys:
      - ssh-dss AAAABBBBBCCCCDDDD...
runcmd:
  - sed -i -e 's/#Protocol 2/Protocol 2/g' /etc/ssh/sshd_config
  - sed -i -e 's/#LoginGraceTime 2m/LoginGraceTime 2m/g' /etc/ssh/sshd_config
  - sed -i -e 's/#PermitRootLogin yes/PermitRootLogin no/g' /etc/ssh/sshd_config
  - sed -i -e 's/PasswordAuthentication yes/PasswordAuthentication no/g' /etc/ssh/sshd_config
  - sed -i -e 's/#RSAAuthentication yes/RSAAuthentication yes/g' /etc/ssh/sshd_config
  - sed -i -e 's/#PubkeyAuthentication yes/PubkeyAuthentication yes/g' /etc/ssh/sshd_config
  - sed -i -e '$aAllowUsers admin' /etc/ssh/sshd_config
  - service sshd restart

  #firewall
  - systemctl start firewalld
  - firewall-cmd --permanent --add-service=ssh
  - firewall-cmd --reload
  - systemctl enable firewalld
centosrhelsecuritysshdpublic-key-authentication
2
frank

ほとんどの質問に対する答えではありませんが、コメントするには長すぎます。

  1. 別のユーザー（「admin」など）を使用する理由は、認証/承認のもう1つのレイヤー（キー/パスワードを使用してユーザーとしてログインし、rootになるために別のパスワードを入力する）を画像に配置するためです。 。ユーザーがrootと同じUIDを持っていない限り、rootと同じ権限はありませんが、「通常の」ユーザーよりも大きな権限を持っている可能性があります。

    また、異なるユーザーに同じアカウントへのアクセスを許可することもできます。1つのアカウントを異なるキーで認証できます。これにより、複数のユーザー（および複数のマシン）がある場合に作業が簡単になります。特定のユーザーの権限を他のユーザーに割り込まずに取り消すには、AuthorizedKeysファイル（通常は〜/ .ssh/authorized_keys`）から1つのエントリを削除するだけです。 。（同じことが明らかに直接ルートアクセスにも当てはまりますが、追加の認証/承認レベルはありません。）

    攻撃者がキーを利用できるかどうかについては、キーの公開部分のみがサーバーに保持されます（保持されます）。認証フェーズでは、クライアントは自分の秘密鍵を使用しますが、サーバー上のどこにも残しません。したがって、サーバーでroot権限を取得した人は、通常のユーザーとしてリモートでログインする機能を取得できません（つまり、そのマシンに自分の秘密鍵を保持しません）。

    他のことについては、通常が成り立ちます：
    Q：「システムでroot権限を取得した人をどのように呼び出しますか？」
    A： "はい、サー。"

  2. コマンドラインの前に「Sudo」を付けるだけで、すべてのユーザーがroot権限でコマンドを実行できるようにすることは、Sudoの完全な誤用です。これは素晴らしいアイデアだと考える人もいますが、セキュリティに関しては、実際にはすべての人がシステム管理者になるため、これは最も愚かなことの1つです。唯一の利点は、昇格された特権で誤って_rm -Rf /_を実行しないことです（rootとして直接ログインする場合のように）。しかし、その後、筋肉の記憶が引き継がれ、人々はどこでもSudoを使い始めます。残っている唯一の利点は、コマンドをログに記録できることです。あなたが正しく気づいたように、それはまた二次口座の目的を無効にします。

    要するに：ALL=(ALL) NOPASSWD:ALLは悪い考えですTM、サーバーでは二重にそうです。しないでください。

    あなたがそれを取り除くと、突然パート1）がより意味をなし始めます。

1
peterph

CentOS 7 Security Hardening 私が投稿したばかりのドキュメントが役立つかもしれません。これはOpenSCAPに基づいています。

1
Arr0way