4.3. サービスのセキュア化

組織内のシステム管理者にとっては管理機能へのユーザーアクセスは重要な問題ですが、どのネットワークサービスがアクティブかを監視することは、Linux システムのすべての管理・運営担当者にとっての最重要事項です。
Red Hat Enterprise Linux 7 における多くのサービスは、ネットワークサーバーとして動作します。マシン上でネットワークサービスが稼働中であれば、(デーモン と呼ばれる) サーバーアプリケーションが 1 つ以上のネットワークポート上での接続をリッスンします。これらの各サーバーは、潜在的な攻撃の接近手段として扱われる必要があります。

4.3.1. サービスへのリスク

ネットワークサービスは Linux システムに多くのリスクを与える可能性があります。主な問題を以下に挙げます。
  • サービス拒否攻撃 (DoS) — サービス拒否攻撃は、サービスに対して要求を大量に送信することでシステムがすべての要求をログ記録・応答しようとし、使用不可能になります。
  • 分散型サービス拒否攻撃 (DDoS) — これは DoS 攻撃の一種で、複数の脆弱なマシンを使用し (通常、数千以上)、サービスに対して一斉攻撃を仕掛けます。大量の要求が送信され、サービスを使用不可能にしてしまいます。
  • スクリプトの脆弱性への攻撃 — Web サーバーが通常行うように、サーバー全体のアクションにサーバーがスクリプトを使用している場合、攻撃者は誤って書かれたスクリプトを狙うことができます。このスクリプトの脆弱性に対する攻撃により、バッファがオーバーフロー状態になるか、攻撃者がシステム上のファイルを変更できる可能性があります。
  • バッファーオーバーフロー攻撃 — ポート 1〜1023 でリッスンするサービスを起動するには、管理権限を使用するか、CAP_NET_BIND_SERVICE 機能を設定する必要があります。プロセスがポートにバインドされ、そのポートでリッスンしている場合は、権限または機能が破棄されることがよくあります。権限または機能が破棄されず、アプリケーションに利用可能なバッファーオーバーフローがある場合、攻撃者はデーモンを実行中のユーザーとしてシステムにアクセスすることができます。利用可能なバッファーオーバーフローが存在するため、クラッカーは自動ツールを使って脆弱性のあるシステムを特定でき、アクセスを確保した後に自動ルートキットを使ってシステムへのアクセスを維持します。

注記

Red Hat Enterprise Linux 7 では、ExecShield と呼ばれる x86 互換のシングルおよびマルチプロセッサーのカーネルがサポートする実行可能メモリのセグメント化および保護技術により、バッファオーバーフローの脆弱性における脅威は緩和されています。ExecShield は仮想メモリを実行可能なセグメントと非実行可能セグメントに分けることでバッファオーバーフローのリスクを下げます。(バッファオーバーフローエクスプロイトから注入された悪意のあるコードなど) 実行可能セグメント外で実行を試みるすべてのプログラムコードは、セグメント化の失敗を発生させ、終了します。
Execshield には AMD64 プラットフォーム上の No eXecute (NX) と Intel® 64 システムのサポートが含まれます。これらのテクノロジーが ExecShield と組み合わさることで、4 KB の実行可能コードという粒度で仮想メモリの実行可能な部分での悪意のあるコードの実行を防ぎます。これで、バッファオーバーフローエクスプロイトからの攻撃リスクを減らします。

重要

ネットワーク上での攻撃への露出を限定するために、使用していないサービスはすべてオフにすることが推奨されます。

4.3.2. サービスの特定および設定

セキュリティを強化するために、Red Hat Enterprise Linux 7 でインストールされているネットワークサービスのほとんどはデフォルトでオフとなっています。ただし、以下のものは例外となります。
  • cups — Red Hat Enterprise Linux 7 のデフォルトのプリントサーバー
  • cups-lpd — 代替プリントサーバー
  • xinetdgssftptelnet などの下位サーバーへの接続を管理するスーパーサーバー
  • sshd — Telnet の安全な代替となる OpenSSH サーバー
これらサービスの稼働を継続しておくかどうかを判断する際は、常識にしたがってリスクを避けるのが最善策です。例えば、プリンターが利用できない場合は cups を無効にします。同じことは portreserve についても言えます。NFSv3 ボリュームをマウントしていなかったり、NIS (ypbind サービス) を使用しないのであれば、rpcbind を無効にすべきです。ブート時にどのネットワークサービスが開始可能になっているかを確認するだけでは、十分ではありません。どのポートがオープンでリッスンしているかを確認することが推奨されます。詳細情報は、「リッスンしているポートの確認」 を参照してください。

4.3.3. 安全でないサービス

潜在的にはどのネットワークサービスも安全ではありません。未使用のサービスをオフにすることが重要なのは、このためです。サービスのエクスプロイトは定期的に発見され修正プログラムが提供されているので、ネットワークサービスはどんなものでも関連するパッケージを定期的に更新することが非常に重要です。詳細は 3章システムを最新の状態に保つ を参照してください。
ネットワークプロトコルの中には、もともと他のものよりも安全性が低いものがあります。以下の動作を実行するサービスがそれに当たります。
  • 暗号化されていないネットワークでユーザー名やパスワードを送信する — Telnet や FTP など多くの古いプロトコルは認証セッションを暗号化しないので、できるだけ避けてください。
  • 暗号化されていないネットワークで機密性の高いデータを送信する — Telnet や FTP、HTTP、SMTP など多くのプロトコルでは暗号化されていないネットワークでデータを送信します。また、NFS や SMB などの多くのネットワークファイルシステムでも暗号化されていないネットワークで情報を送信します。これらのプロトコルを使用する際に送信するデータの種類を制限することは、ユーザーの責任になります。
もともと安全性が低いサービスには、rloginrshtelnetvsftpd などがあります。
リモートログインおよびシェルプログラム (rloginrshtelnet) はすべて避けて、SSH を使用するようにしてください。sshd に関する詳細については、「SSH のセキュア化」を参照してください。
FTP は、システムのセキュリティーにとってリモートシェルほど危険ではありませんが、問題を回避するには FTP サーバーを慎重に設定し、監視する必要があります。FTP サーバーのセキュア化に関する詳細については、「FTP のセキュア化」を参照してください。
実装時に注意が必要で、ファイアウォールの背後に配置する必要があるサービスは以下のものです。
  • auth
  • nfs-server
  • smb および nbm (Samba)
  • yppasswdd
  • ypserv
  • ypxfrd
ネットワークサービスの安全性を高めるための詳細情報は、「ネットワークアクセスのセキュア化」 を参照してください。

4.3.4. rpcbind のセキュア化

rpcbind サービスは、NIS やNFS などの RPC サービス用の動的なポート割り当てデーモンです。この認証メカニズムは脆弱なもので、制御対象のサービスに幅広いポートを割り当てる機能があります。このため、セキュア化は困難になります。

注記

NFSv4 は rpcbind を必要としなくなったので、portmap のセキュア化が影響するのは NFSv2 と NFSv3 のみです。NFSv2 もしくは NFSv3 サーバーの導入を計画する場合は、rpcbind が必要となり、以下のセクションが適用されます。
RPC サービスを実行している場合は、以下の基本的なルールにしたがってください。

4.3.4.1. TCP Wrapper による rpcbind の保護

rpcbind にはビルトインの認証がないので、TCP Wrapper を使用して rpcbind サービスにアクセスするネットワークやホストを制限することが重要です。
さらに、サービスへのアクセスを制限する際には、IP アドレス のみ を使用してください。ホスト名は DNS ポイズニングやその他の方法で偽造される恐れがあるので、使用しないでください。

4.3.4.2. firewalld による rpcbind の保護

rpcbind サービスへのアクセスをさらに制限するには、サーバーに firewalld ルールを追加し、特定ネットワークへのアクセスを制限するとよいでしょう。
以下は、 firewalld リッチ言語コマンドの 2 つの例です。最初のコマンドは 192.168.0.0/24 ネットワークからポート 111 (rpcbind サービスが使用) への TCP 接続を許可します。2 つ目のコマンドは、ローカルホストからの同一ポートへの接続を許可します。他のパケットはすべて遮断されます。
~]# firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="192.168.0.0/24" invert="True" drop'
~]# firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="127.0.0.1" accept'
UDP トラフィックを同様に制限するには、以下のコマンドを使用します。
~]# firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="udp" source address="192.168.0.0/24" invert="True" drop'

注記

設定を永続的にするには、--permanentfirewalld リッチ言語コマンドに追加します。ファイアウォールの実装に関する詳細情報は、「ファイアウォールの使用」 を参照してください。

4.3.5. rpc.mountd のセキュア化

rpc.mountd デーモンは、NFS バージョン 2 (RFC 1904) と NFS バージョン 3 (RFC 1813) で使用されているプロトコルである NFS MOUNT プロトコルのサーバーサイドを実装します。
RPC サービスを実行している場合は、以下の基本的なルールにしたがってください。

4.3.5.1. TCP Wrappers による rpc.mountd の保護

rpc.mountd には認証が組み込まれていないため、TCP Wrapper を使用して rpc.mountd サービスにアクセスするネットワークやホストを制限することが重要です。
さらに、サービスへのアクセスを制限する際には、IP アドレス のみ を使用してください。ホスト名は DNS ポイズニングやその他の方法で改ざんできるため、使用しないでください。

4.3.5.2. firewalld による rpc.mountd の保護

rpc.mountd サービスへのアクセスをさらに制限するには、サーバーに firewalld リッチ言語ルールを追加し、特定のネットワークへのアクセスを制限します。
以下は、 firewalld リッチ言語コマンドの 2 つの例です。最初のコマンドでは、192.168.0.0/24 ネットワークからの mountd 接続を許可します。2 つ目のコマンドでは、ローカルホストからの mountd 接続を許可します。他のパケットはすべて遮断されます。
~]# firewall-cmd --add-rich-rule 'rule family="ipv4" source NOT address="192.168.0.0/24" service name="mountd" drop'
~]# firewall-cmd --add-rich-rule 'rule family="ipv4" source address="127.0.0.1" service name="mountd" accept'

注記

設定を永続的にするには、--permanentfirewalld リッチ言語コマンドに追加します。ファイアウォールの実装に関する詳細情報は、「ファイアウォールの使用」 を参照してください。

4.3.6. NIS のセキュア化

ネットワーク情報サービス (NIS) は ypserv と呼ばれる RPC サービスの一つで、rpcbind および他の関連サービスと一緒に使用することで、ドメイン内にあると主張するすべてのコンピューターに、ユーザー名やパスワード、他の機密性のある情報のマップを配布します。
NIS サーバーは、以下のものを含むいくつかのアプリケーションで構成されています。
  • /usr/sbin/rpc.yppasswddyppasswdd サービスとも呼ばれます。このデーモンを使用することで、ユーザーは NIS パスワードを変更できます。
  • /usr/sbin/rpc.ypxfrdypxfrd サービスとも呼ばれます。このデーモンは、ネットワーク上での NIS マップ転送を担当します。
  • /usr/sbin/ypserv — これは NIS サーバーデーモンです。
NIS は今日の基準ではあまり安全なものではありません。ホスト認証メカニズムがなく、パスワードハッシュを含むすべての情報をネットワーク上で暗号化せずに送信します。このため、NIS を使用するネットワークの設定時には、非常に注意深い作業が必要になります。さらに、NIS のデフォルト設定がもともと安全でないことで複雑性が増してしまいます。
NIS サーバーの実装を予定している場合は、「rpcbind のセキュア化」 に概説があるようにまず rpcbind サービスのセキュア化を図ることが推奨されます。その後に、以下のようなネットワークプラニングの問題などに対処してください。

4.3.6.1. ネットワークの注意深いプラニング

NIS は機密性の高い情報を暗号化せずにネットワーク上で送信するので、ファイアウォールの背後で、またセグメント化された安全なネットワーク上で実行することが重要です。NIS 情報が安全でないネットワーク上で送信される際は、常に傍受される危険があります。ネットワークを注意深く設計することで、重大なセキュリティ侵害の防止に役立ちます。

4.3.6.2. パスワードのような NIS ドメイン名およびホスト名を使用する

ユーザーが NIS サーバーの DNS ホスト名と NIS ドメイン名を知っていれば、NIS ドメイン内のマシンはどれもコマンドを使用して認証なしにサーバーから情報を引き出すことができます。
例えば、だれかがノートパソコンをネットワークに接続するか、外部からネットワークに侵入すると (そして内部 IP アドレスにスプーフィングできたとすると)、以下のコマンドが /etc/passwd マップを公開します。
ypcat -d <NIS_domain> -h <DNS_hostname> passwd
この攻撃者が root ユーザーであった場合、以下のコマンドを入力して /etc/shadow ファイルを入手することが可能です。
ypcat -d <NIS_domain> -h <DNS_hostname> shadow

注記

Kerberos を使用していれば、/etc/shadow ファイルは NIS マップ内に保存されません。
攻撃者による NIS マップへのアクセスをより困難にするには、o7hfawtgmhwg.domain.com のようなランダムの文字列を DNS ホスト名にします。同様に、異なる ランダムな NIS ドメイン名を作成します。これにより、攻撃者は NIS サーバーへのアクセスが非常に困難になります。

4.3.6.3. /var/yp/securenets ファイルを編集する

/var/yp/securenets ファイルが空白もしくは存在しない場合 (デフォルトインストールの後の場合のように)、NIS はすべてのネットワークをリッスンします。最初にすることのひとつは、ネットマスクとネットワークのペアをファイルに置くことで、これにより ypserv は適正なネットワークからの要求のみに応答するようになります。
以下は /var/yp/securenets ファイルからのエントリのサンプルです。
255.255.255.0     192.168.0.0

警告

/var/yp/securenets ファイルを作成せずに NIS サーバーを初回起動することは、絶対にしないでください。
このテクニックは IP スプーフィングからの保護は提供しませんが、少なくとも NIS サーバーが対応するネットワークに対して制限をかけます。

4.3.6.4. 静的ポートの割り当てとリッチ言語ルールの使用

NIS に関連付けられているサーバーは、rpc.yppasswdd を除いて特定のポートの割り当てが可能です。このデーモンを使うと、ユーザーは自身のログインパスワードを変更できるようになります。rpc.ypxfrdypserv の 2 つの NIS サーバーデーモンにポートを割り当てると、NIS サーバーデーモンをさらに侵入者から保護するためのファイアウォールルールが作成できます。
これを実行するには、以下の行を /etc/sysconfig/network に追加します。
YPSERV_ARGS="-p 834"
YPXFRD_ARGS="-p 835"
以下のリッチ言語の firewalld ルールを使って、これらのポートでサーバーがリッスンするネットワークを強制できます。
~]# firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.0.0/24" invert="True" port port="834-835" protocol="tcp" drop'
~]# firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.0.0/24" invert="True" port port="834-835" protocol="udp" drop'
つまり、192.168.0.0/24 ネットワークからの要求であれば、サーバーはポート 834 および 835 への接続のみを許可することになります。最初のルールは TCP のもので、2 つ目は UDP になります。

注記

iptables コマンドによるファイアウォール実装についての詳細情報は、「ファイアウォールの使用」 を参照してください。

4.3.6.5. Kerberos 認証を使用する

認証に NIS を使用する際に考慮すべきことの一つは、ユーザーがマシンにログインする際は常に、/etc/shadow マップからのパスワードハッシュがネットワーク上で送信されるということです。侵入者が NIS ドメインへアクセスしてネットワークトラフィックを傍受した場合、ユーザー名とパスワードハッシュを取得できることになります。さらに時間があれば、攻撃者はパスワードクラッキングプログラムで脆弱なパスワードを推測し、ネットワーク上の有効なアカウントへのアクセスを取得できるようになります。
Kerberos は秘密鍵の暗号作成方法を使用するので、パスワードハッシュがネットワーク上で送信されることはなく、システムを大幅に安全なものとします。Kerberos についての詳細は、Linux Domain Identity, Authentication, and Policy Guide の Authentication: Kerberos KDC のセクションを参照してください。

4.3.7. NFS のセキュア化

重要

NFS トラフィックは全バージョンで TCP を使用して送信することが可能で、UDP ではなく NFSv3 を使って送信してください。NFS のバージョンはすべて、RPCSEC_GSS カーネルモジュールの一部として Kerberos ユーザーおよびグループ認証をサポートしています。Red Hat Enterprise Linux 7 では rpcbind を使用する NFSv3 がサポートされているので、rpcbind に関する情報も引き続き含まれています。

4.3.7.1. ネットワークの注意深いプラニング

NFSv2 と NFSv3 ではこれまで、データの受け渡しは安全に行われていませんでした。今では NFS の全バージョンで Kerberos を使った通常のファイルシステム操作の認証 (およびオプションで暗号化) ができます。NFSv4 では、すべての操作で Kerberos の使用が可能です。v2 または v3 では、ファイルロックとマウントにまだ Kerberos が使用されていません。NFSv4 使用時は、クライアントが NAT もしくはファイアウォールの背後にあるのであれば、委任はオフにすることができます。NFSv4.1 を使って NAT およびファイアウォールを通じた委任による操作を可能にする方法については、Red Hat Enterprise Linux 7 ストレージ管理ガイドの pNFS のセクションを参照してください。

4.3.7.2. NFS マウントオプションのセキュア化

/etc/fstab ファイル内での mount コマンド使用については、Red Hat Enterprise Linux 7 ストレージ管理ガイドの mount コマンドの使い方 の章で説明されています。セクション管理の観点からは、NFS マウントオプションは /etc/nfsmount.conf でも指定可能であることは注目に値します。これを使うと、カスタムのデフォルトオプションを設定することが可能です。
4.3.7.2.1. NFS サーバーのレビュー

警告

ファイルシステムをエクスポートする際は、全体のエクスポートのみを行なってください。ファイルシステムのサブディレクトリーをエクスポートすると、セキュリティ問題につながる可能性があります。場合によってはクライアントがファイルシステムのエクスポートされた部分から抜け出し、エクスポートされていない部分に至ることもあります (exports(5) man ページのサブツリーチェックのセクションを参照)。
マウント済みファイルシステムへの書き込み可能なユーザー数を減らすためには、可能な場合は常に ro オプションを使用してファイルシステムを読み取り専用としてエクスポートしてください。rw オプションの使用は、明確に必要な場合のみとしてください。詳細は exports(5) man ページを参照してください。書き込みアクセスを許可すると、シンボリックリンク攻撃などのリスクが高まります。これには、/tmp/usr/tmp などの一時ディレクトリーが含まれます。
ディレクトリーを rw オプションでマウントする必要がある場合は、リスク低減のためにできる限り全ユーザー書き込み可能としないようにします。アプリケーションのなかにはパスワードをクリアテキストで保存したり暗号化が弱いものもあるので、ホームディレクトリーのエクスポートもリスクとみなされます。このリスクは、アプリケーションコードがレビューされ、改善されることで軽減されてきています。SSH キーにパスワードを設定しないユーザーもいるので、ホームディレクトリーがリスクをもたらすことになります。パスワードや Kerberos の使用を強制することで、このリスクは緩和されます。
エクスポートはアクセスを必要とするクライアントのみとしてください。NFS サーバーで showmount -e コマンドを使用して、サーバーが何をエクスポートしているかを確認します。特に必要でないものはエクスポートしないでください。
no_root_squash オプションは使用しないでください。また、既存のインストールのレビューを行い、これが使用されていないことを確認してください。詳細は 「no_root_squash オプションは使用しないでください」 を参照してください。
secure オプションはサーバー側のエクスポートオプションで、予約済み ポートへのエクスポートを制限する際に使用します。デフォルトでは、サーバーは 予約済み ポート (ポート番号 1024 未満のもの) からのクライアント通信のみを許可します。これは、クライアントが通常これらのポートの使用を許可するのは 信頼できる コード (カーネル内の NFS クライアントなど) のみだったためです。しかし、多くのネットワークではクライアント上で root になるのは難しいことではないので、予約済みポートからの通信が権限を伴うものであると仮定するのは安全ではありません。このため、予約済みポートへの制限は限定的な価値しかありません。Kerberos やファイアウォール、エクスポートを特定のクライアントに制限するという方法を信頼する方がより安全です。
ほとんどのクライアントは、未だに予約済みポートを使用しています (可能な場合)。ただし、予約済みポートは限定的なリソースなので、クライアント (特に NFS マウント数が多いもの) はより大きい番号のポートを使う選択をする場合もあります。Linux クライアントは、noresvport マウントオプションを使用してこれを行うことができます。エクスポートでこれを許可したい場合は、insecure エクスポートオプションで行うことができます。
ユーザーがサーバーにログインできないようにしておくのは、よい方法です。上記の NFS サーバー設定を確認する間に、誰および何がサーバーにアクセス可能かを確認してください。
4.3.7.2.2. NFS クライアントのレビュー
setuid プログラムを使用できないようにするには、nosuid オプションを使用します。nosuid オプションは set-user-identifier または set-group-identifier ビットを無効にします。これにより、リモートユーザーが setuid プログラムを実行してより高い権限を取得することを防ぎます。このオプションは、クライアントおよびサーバー側で使用してください。
noexec オプションはクライアント上のすべての実行可能ファイルを無効にします。共有しているファイルシステムにあるファイルをユーザーが不注意で実行しないようにこのオプションを使用します。nosuid および noexec オプションは、ほとんどのファイルシステムの標準オプションです。
nodev オプションを使うと、クライアントが device-files をハードウェアデバイスとして処理することを防ぎます。
resvport オプションはクライアント側のマウントオプションで、secure はこれに対応するサーバー側のエクスポートオプションです (上記の説明を参照)。これは「予約済みポート」への通信を制限します。予約済みまたは「よく知られた」ポートは、root ユーザーなどの権限のあるユーザーやプロセス用に確保されています。このオプションを設定すると、クライアントが予約済みソースのポートを使ってサーバーと通信するようになります。
NFS の全バージョンですでに Kerberos 認証に対応しています。これを有効にするマウントオプションは、次の通りです。sec=krb5
NFSv4 は、整合性には krb5i を、プライバシー保護には krb5p を使用して Kerberos によるマウントをサポートします。これらは sec=krb5 でのマウント時に使用されますが、NFS サーバー上での設定が必要です。詳細はエクスポートに関する man ページ (man 5 exports) を参照してください。
NFS man ページ (man 5 nfs) には SECURITY CONSIDERATIONS セクションがあり、ここでは NFSv4 のセキュリティ強化の説明と NFS の特定のマウントオプションすべてが含まれています。

4.3.7.3. 構文エラーに注意

NFS サーバーは /etc/exports ファイルを参照して、エクスポートするファイルシステムとこれらのディレクトリーをエクスポートするホストを決定します。このファイルを編集する際は、無関係な領域を追加しないように注意してください。
例えば、/etc/exports ファイル内の以下の行は読み取り/書き込みパーミッションでディレクトリー /tmp/nfs/ をホスト bob.example.com と共有します。
/tmp/nfs/     bob.example.com(rw)
一方、/etc/exports ファイルは同じディレクトリーを読み取り専用パーミッションでホスト bob.example.com と共有し、ホスト名の後ろに一文字分の空白があるので読み取り/書き込みパーミッションで world と共有します。
/tmp/nfs/     bob.example.com (rw)
showmount コマンドを使って何が共有されているかを検証するのは、設定済み NFS 共有をチェックするよい方法です。
showmount -e <hostname>

4.3.7.4. no_root_squash オプションは使用しないでください

デフォルトで NFS 共有は、root ユーザーを権限のないユーザーアカウントである nfsnobody ユーザーに変更します。これにより、root で作成された全ファイルの所有者は nfsnobody に変更されます。この変更で setuid ビットが設定されたプログラムのアップロードが防止されます。
no_root_squash を使用すると、リモートの root ユーザーは共有ファイルシステム上のどのファイルも変更できるようになり、トロイの木馬に感染したアプリケーションを他のユーザーが間違って実行できる状態にしてしまいます。

4.3.7.5. NFS ファイアウォールの設定

Red Hat Enterprise Linux 7 のデフォルトの NFS は NFSv4 で、この場合は TCP でポート 2049 が開いていれば問題ありません。NFSv3 を使用していると、以下の説明にあるように、さらに 4 つのポートが必要になります。
NFSv3 用のポート設定
NFS に使用されるポートは rpcbind が動的に割り当てますが、ファイアウォールルールの作成時に問題を起こす恐れがあります。このプロセスを簡素化するには、/etc/sysconfig/nfs ファイルを使って使用するポートを特定します。
  • MOUNTD_PORT — mountd (rpc.mountd) 用の TCP および UDP ポート
  • STATD_PORT — status (rpc.statd) 用の TCP および UDP ポート
  • LOCKD_TCPPORT — nlockmgr (rpc.lockd) 用 TCP ポート
  • LOCKD_UDPPORT — nlockmgr (rpc.lockd) 用 UDP ポート
指定されたポート番号は、他のサービスが使用してはいけません。ポート番号の指定と TCP および UDP ポート 2049 (NFS) を許可するようにファイアウォールを設定してください。
NFS サーバーで rpcinfo -p コマンドを実行し、どのポートと RPC プログラムが使用されているかを確認します。

4.3.8. Apache HTTP サーバーのセキュア化

Apache HTTP サーバーは Red Hat Enterprise Linux 7 に同梱されているサービスのなかで最も安定性があり安全なものの一つです。Apache HTTP サーバーを安全にするには多くのオプションとテクニックがあり、ここで詳述するには多すぎるほどです。以下のセクションでは、Apache HTTP サーバー稼働時に実行できる優れた方法を簡単に説明します。
スクリプトを実稼働環境で実行する 前に、常にそのシステムがシステム上で意図したとおりに稼働していることを確認してください。また、スクリプトもしくは CGI を含むディレクトリーに書き込みパーミッションを持っているのは root ユーザーのみであることを確認してください。これを行うには、root ユーザーで以下のコマンドを実行します。
chown root <directory_name>
chmod 755 <directory_name>
以下の設定オプションを (/etc/httpd/conf/httpd.conf 内の設定で) 使用する際は、システム管理者は注意してください。
FollowSymLinks
このディレクティブはデフォルトで有効となっているので、Web サーバーのドキュメントルートへのシンボリックリンク作成時には注意してください。例えば、/ へのシンボリックリンクを提供することはよい方法ではありません。
Indexes
このディレクティブはデフォルトで有効となっていますが、これが最適ではない可能性があります。ビジターがサーバー上のファイル閲覧をできないようにするには、このディレクティブを削除します。
UserDir
UserDir はシステム上でのユーザーアカウントの有無を確認できるので、デフォルトでは無効となっています。サーバー上のユーザーディレクトリーのブラウジングを有効にするには、以下のディレクティブを使用します。
UserDir enabled
        UserDir disabled root
これらのディレクティブは、/root/ 以外のすべてのユーザーディレクトリーのブラウジングを有効にします。無効アカウントリストにユーザーを追加するには、UserDir disabled 行に空白で区切ったユーザーのリストを追加します。
サーバートークン
サーバートークン ディレクティブは、クライアントに返信されるサーバー応答ヘッダーフィールドを制御します。これには、以下のパラメーターを使用してカスタマイズできる種々の情報が含まれます。
  • ServerTokens Full (デフォルトのオプション) — (OS の種類や使用されるモジュールなど) 利用可能なすべての情報を提供します。例えば、
    Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2
    
  • ServerTokens Prod または ServerTokens ProductOnly — 以下の情報を提供します。
    Apache
    
  • ServerTokens Major — 以下の情報を提供します。
    Apache/2
    
  • ServerTokens Minor — 以下の情報を提供します。
    Apache/2.0
    
  • ServerTokens Min または ServerTokens Minimal — 以下の情報を提供します。
    Apache/2.0.41
    
  • ServerTokens OS — 以下の情報を提供します。
    Apache/2.0.41 (Unix)
    
潜在的な攻撃者がユーザーのシステムについて価値ある情報を取得できないないようにするには、ServerTokens Prod の使用が推奨されます。

重要

IncludesNoExec ディレクティブは削除しないでください。デフォルトでは、Server-Side Includes (SSI) モジュールはコマンドの実行ができません。絶対に必要な場合以外は、この設定を変更しないことが推奨されます。変更すると、攻撃者がシステム上でコマンドを実行できるようになる可能性があります。

httpd モジュールの削除

特定のシナリオでは、特定の httpd モジュールを削除して HTTP サーバーの機能を制限した方がよい場合もあります。これは、/etc/httpd/conf/httpd.conf ファイルで削除したいモジュールをロードし行全体をコメントアウトするだけで行えます。たとえば、プロキシモジュールを削除するには、以下の行の先頭にハッシュ記号を加えてコメントアウトします。
#LoadModule proxy_module modules/mod_proxy.so
/etc/httpd/conf.d/ ディレクトリーにもモジュールの読み込みに使われる設定ファイルが含まれていることに注意してください。

httpd および SELinux

詳細情報は、Red Hat Enterprise Linux 7 SELinux User's and Administrator's Guide の The Apache HTTP Server and SELinux の章を参照してください。

4.3.9. FTP のセキュア化

File Transfer Protocol (FTP) は旧式の TCP プロトコルで、ネットワーク上でファイル転送するために設計されています。ユーザー認証を含むサーバーとのトランザクションがすべて暗号化されないので、安全でないプロトコルとみなされ、慎重に設定する必要があります。
Red Hat Enterprise Linux 7 は以下の 2 つの FTP サーバーを提供します。
  • Red Hat Content Accelerator (tux) — FTP 機能のあるカーネル空間の Web サーバーです。
  • vsftpd — スタンドアロンでセキュリティ重視の FTP サービス実装です。
以下のセキュリティガイドラインは vsftpd FTP サービス設定のためのものです。

4.3.9.1. FTP グリーティングバナー

ユーザー名とパスワードの送信前に、すべてのユーザーにグリーティングバナーが示されます。デフォルトでは、このバナーにはシステムの脆弱性を特定しようとしているクラッカーに有益なバージョン情報が含まれています。
vsftpd のグリーティングバナーを変更するには、以下のディレクティブを /etc/vsftpd/vsftpd.conf ファイルに追加します。
ftpd_banner=<insert_greeting_here>
上記のディレクティブの <insert_greeting_here> をグリーティングメッセージのテキストで置き換えます。
複数行のバナーの場合、バナーファイルの使用が最善の方法となります。複数のバナーの管理を簡素化するには、/etc/banners/ という新規ディレクトリーにすべてのバナーを格納します。この例では、FTP 接続のバナーファイルは、/etc/banners/ftp.msg となります。以下はこのファイルのサンプルになります。
######### Hello, all activity on ftp.example.com is logged. #########

注記

「TCP Wrapperおよび xinetd によるサービスのセキュア化」 にあるように、各行を 220 で始める必要はありません。
vsftpd でこのバナーを参照するようにするには、以下のディレクティブを /etc/vsftpd/vsftpd.conf ファイルに追加します。
banner_file=/etc/banners/ftp.msg
「TCP Wrapper と接続バナー」 にあるように、 TCP Wrapper を使って着信接続に新たなバナーを送信することも可能です。

4.3.9.2. 匿名のアクセス

/var/ftp/ ディレクトリーが存在すると、匿名アカウントがアクティベートされます。
このディレクトリーを作成する最も簡単な方法は、vsftpd パッケージをインストールすることです。このパッケージは、匿名ユーザー向けのディレクトリーツリーを確立し、匿名ユーザーによる読み取り専用のパーミッションをディレクトリーに設定します。
デフォルトでは、匿名ユーザーはどのディレクトリーにも書き込みできません。

警告

FTP サーバーへの匿名アクセスを有効にする場合は、機密性の高いデータの保存場所に注意してください。
4.3.9.2.1. 匿名のアップロード
匿名ユーザーによるファイルのアップロードを許可する場合は、/var/ftp/pub/ 内に書き込み専用のディレクトリーを作成することが推奨されます。これを行うには、以下のコマンドを root で実行します。
~]# mkdir /var/ftp/pub/upload
次に、パーミッションを変更して、匿名ユーザーがディレクトリーのコンテンツを閲覧できないようにします。
~]# chmod 730 /var/ftp/pub/upload
ディレクトリーのロング形式での一覧は以下のようなります。
~]# ls -ld /var/ftp/pub/upload
drwx-wx---. 2 root ftp 4096 Nov 14 22:57 /var/ftp/pub/upload
管理者が匿名ユーザーによるディレクトリー内での書き込みや読み取りを許可すると、そのサーバーが盗難ソフトウェアのレポジトリになってしまう場合が多くあります。
vsftpd で、以下の行を /etc/vsftpd/vsftpd.conf ファイルに追加します。
anon_upload_enable=YES

4.3.9.3. ユーザーアカウント

FTP は安全でないネットワーク上で認証用のユーザー名とパスワードを暗号化せずに送信するので、ユーザーアカウントからサーバーへのシステムユーザーアクセスを拒否することはよい方法です。
vsftpd のすべてのユーザーアカウントを無効にするには、以下のディレクティブを /etc/vsftpd/vsftpd.conf に追加します。
local_enable=NO
4.3.9.3.1. ユーザーアカウントの制限
root ユーザーや sudo 権限を持つユーザーなど、特定のアカウントや特定のアカウントグループの FTP アクセスを無効にする最も簡単な方法は、「Root アクセスの拒否」 にあるように PAM リストファイルを使用することです。vsftpd の PAM 設定ファイルは、/etc/pam.d/vsftpd です。
また、各サービス内で直接ユーザーアカウントを無効にすることもできます。
vsftpd で特定のユーザーアカウントを無効にするには、ユーザー名を /etc/vsftpd/ftpusers に追加します。

4.3.9.4. TCP Wrapper を使用してアクセスを制御する

FTP デーモンへのアクセスを制御するには、「TCP Wrapperおよび xinetd によるサービスのセキュア化」 にあるように TCP Wrapper を使用します。

4.3.10. Postfix のセキュア化

Postfix は メール転送エージェント (MTA) で、他の MTA や Email クライアント、配信エージェント間で電子メッセージを配信するために Simple Mail Transfer Protocol (SMTP) を使用します。多くの MTA には MTA 間のトラフィックを暗号化する機能がありますが、ほとんど使用されていないので、公開ネットワーク上での Email 送信はもともと安全でない通信方法とみなされています。Postfix は Red Hat Enterprise Linux 7 のデフォルトの MTA として Sendmail に代わるものです。
Postfix サーバーの実装を計画している場合は、以下の問題に対処することが推奨されます。

4.3.10.1. サービス拒否攻撃を制限する

Email の性質上、攻撃者が本気になるとサーバーに大量のメールを送信し、サービス拒否を発生させることが簡単にできます。/etc/postfix/main.cf ファイル内のディレクティブに制限を設定すると、このような攻撃の有効性が制限されます。既存のディレクティブの値を変更するか、以下の形式で希望する値の必要なディレクティブを追加することもできます。
<directive> = <value>
サービス拒否攻撃の制限に使用できるディレクティブを以下に示します。
  • smtpd_client_connection_rate_limit — 一定の時間単位内 (下記を参照) にクライアントが当該サーバーに接続を試みることができる最大回数。デフォルト値は 0 で、この場合クライアントは Postfix が受付可能な回数内で時間単位当たり何回でも接続を試みることができます。デフォルトでは、信頼できるネットワーク内のクライアントは除外されます。
  • anvil_rate_time_unit — この時間単位は割合制限の計算に使用されます。デフォルト値は 60 秒です。
  • smtpd_client_event_limit_exceptions — 接続および割合制限のコマンドから除外されるクライアントです。デフォルトでは、信頼できるネットワーク内のクライアントは除外されます。
  • smtpd_client_message_rate_limit — 時間単位内でクライアントが要求可能な最大メッセージ配信数です (Postfix が実際にこの数のメッセージを受け付けるかどうかは別問題です)。
  • default_process_limit — あるサービスを提供する Postfix の子プロセスの最大デフォルト数です。この制限は、master.cf ファイル内の特定サービスによって無効にされる場合があります。デフォルト値は 100 です。
  • queue_minfree — メール受信に必要なキューファイルシステム内での空き領域の最低バイト数です。これは現在、Postfix SMTP サーバーがメールを受信するかどうかを判断するために使用しています。デフォルトでは、Postfix SMTP サーバーは、空き領域が message_size_limit の 1.5 倍未満であれば MAIL FROM コマンドを拒否します。空き領域の最低限度をより大きくするように指定するには、queue_minfree の値が少なくとも message_size_limit の 1.5 倍になるように指定します。デフォルトの queue_minfree 値は 0 です。
  • header_size_limit — メッセージヘッダー保存に使用するメモリの最大バイト数です。ヘッダーサイズがこの制限を超える場合は、超過分が廃棄されます。デフォルト値は 102400 です。
  • message_size_limit — メッセージの最大バイト数で、これにはエンベロープ情報も含まれます。デフォルト値は 10240000 です。

4.3.10.2. NFS と Postfix

メールスプールディレクトリー /var/spool/postfix/ を NFS 共有ボリュームに配置しないでください。NFSv2 と NFSv3 ではユーザー ID とグループ ID の制御を維持しないので、2 人以上のユーザーが同一 UID を持つ可能性があり、それぞれがお互いのメールを受信、閲覧してしまう可能性があります。

注記

Kerberos を使用する NFSv4 ではこういうことはありません。これは SECRPC_GSS カーネルモジュールが UID ベースの認証を使用しないためです。ただし、それでも NFS 共有ボリュームにメールスプールディレクトリーを 置かない 方がよいと考えられます。

4.3.10.3. メール専用ユーザー

ローカルユーザーによる Postfix サーバーの悪用を避けるには、メールユーザーが Email プログラムを使用して Postfix サーバーにアクセスするだけにするのが最善の方法です。メールサーバー上のシェルアカウントを許可せず、/etc/passwd ファイル内のすべてのユーザーシェルを /sbin/nologin に設定します (root ユーザーは例外とする場合もある)。

4.3.10.4. Postfix ネットワークリスニングの無効化

デフォルトでは、Postfix はローカルのループバックアドレスのみをリッスンするように設定されています。これは、/etc/postfix/main.cf ファイルを表示すると確認できます。
/etc/postfix/main.cf ファイルを閲覧して、以下の inet_interfaces 行のみが表示されることを確認してください。
inet_interfaces = localhost
これにより、Postfix は ネットワークからではなく、(cron ジョブレポートなどの) ローカルシステムからのメールメッセージのみを受信することが確認できます。これがデフォルト設定で、Postfix をネットワーク攻撃から守ります。
ローカルホストの制限を取り除き、Postfix がすべてのインターフェースをリッスンできるようにするには、inet_interfaces = all と設定します。

4.3.10.5. Postfix が SASL を使用する設定

Postfix の Red Hat Enterprise Linux 7 バージョンは、SMTP 認証 (または SMTP AUTH) に Dovecot もしくは Cyrus SASL 実装を使用できます。SMTP 認証は、Simple Mail Transfer Protocol の拡張機能です。これを有効にすると、SMTP クライアントはサーバーとクライアントとの両方でサポートされ、受け入れられている認証方法を使って SMTP サーバーを認証しなくてはなりません。本セクションでは、Dovecot SASL 実装を利用するように Postfix を設定する方法を説明します。
Dovecot POP/IMAP サーバーをインストールして、Dovecot SASL 実装を使用するシステム上で利用可能とするには、root で以下のコマンドを実行します。
~]# yum install dovecot
Postfix SMTP サーバーは、UNIX ドメインソケットTCP ソケット のいずれかを使って Dovecot SASL 実装と通信します。後者の方法は、PostfixDovecot アプリケーションが別個のマシンで実行中の場合にのみ、必要となります。UNIX ドメインソケットの方がよりすぐれたプライバシーを提供するので、本ガイドではこちらを推奨しています。
PostfixDovecot SASL 実装を使用するように指示するには、両方のアプリケーションで多くの設定変更が必要になります。以下の手順にしたがってください。
Dovecot のセットアップ
  1. Dovecot のメインの設定ファイルである /etc/dovecot/conf.d/10-master.conf に以下の行を含めます (デフォルトの設定ファイルには、ほとんどの関連セクションがすでに記載されており、これらの行はコメント解除するだけです)。
    service auth {
      unix_listener /var/spool/postfix/private/auth {
        mode = 0660
        user = postfix
        group = postfix
      }
    }
    上記の例では、PostfixDovecot の通信に UNIX ドメインソケットを使用することを仮定しています。また、Postfix SMTP サーバーの設定はデフォルトとしています。この設定では、メールキューが /var/spool/postfix/ ディレクトリーに配置され、アプリケーションは postfix のユーザーおよびグループで実行されることになります。この方法では、読み取りおよび書き込み許可は、postfix ユーザーおよびグループに限定されます。
    別の方法では、以下の設定を使うと DovecotTCP 経由で Postfix 認証リクエストをリッスンするようになります。
    service auth {
      inet_listener {
        port = 12345
      }
    }
    上記の例では、12345 を、実際に使用するポート番号に置き換えます。
  2. /etc/dovecot/conf.d/10-auth.conf 設定ファイルを編集して、DovecotPostfix SMTP サーバーに plain および login の認証メカニズムを提供するようにします。
    auth_mechanisms = plain login
Postfix のセットアップ
Postfix の場合、メインの設定ファイルである /etc/postfix/main.cf を修正するだけです。以下の設定ディレクティブを追加もしくは編集します。
  1. Postfix SMTP サーバーの SMTP 認証を有効にします。
    smtpd_sasl_auth_enable = yes
  2. Postfix が SMTP 認証に Dovecot SASL 実装を使用するように指示します。
    smtpd_sasl_type = dovecot
  3. Postfix キューディレクトリーの認証相対パスを提供します (相対パスを使用することで、Postfix サーバーが chroot で稼働しているかどうかにかかわらず、この設定が確実に機能するようになります)。
    smtpd_sasl_path = private/auth
    この手順では、PostfixDovecot 間の通信に UNIX ドメインソケットを使用することを前提します。通信に TCP ソケットを使用する場合で、Postfix が別のマシンにある Dovecot を探すように設定するには、以下のような設定値を使用します。
    smtpd_sasl_path = inet:127.0.0.1:12345
    上記の例では、127.0.0.1Dovecot マシンの IP アドレスに、12345Dovecot/etc/dovecot/conf.d/10-master.conf 設定ファイルで指定されているポート番号に置き換えます。
  4. Postfix SMTP サーバーがクライアントに対して利用可能とする SASL メカニズムを指定します。暗号化セッションと非暗号化セッションでは、異なるメカニズムを設定できることに注意してください。
    smtpd_sasl_security_options = noanonymous, noplaintext
    smtpd_sasl_tls_security_options = noanonymous
    上記の例では、非暗号化セッション中は匿名認証が許可されず、また暗号化されていないユーザー名やパスワードを送信するメカニズムも許可されません。(TLS を使った) 暗号化セッションでは、匿名でない認証メカニズムのみが許可されます。
    許可される SASL メカニズムを制限する対応ポリシー全一覧は、http://www.postfix.org/SASL_README.html#smtpd_sasl_security_options を参照してください。
その他のリソース
以下のオンラインのリソースでは、SASL による Postfix SMTP 認証の設定に便利な追加情報が提供されています。

4.3.11. SSH のセキュア化

Secure Shell (SSH) は、セキュアなチャネル上で別のシステムと通信するために使用される強力なネットワークプロトコルです。SSH 上の送信は暗号化され、傍受から保護されます。暗号化ログインを使用して、従来のユーザー名とパスワードよりも優れた認証方法を提供することもできます。SSH プロトコルと Red Hat Enterprise Linux 7 における SSH サービスの使用方法についての一般的な情報は、Red Hat Enterprise Linux 7 システム管理者のガイドの OpenSSH の章を参照してください。

重要

本セクションでは、SSH 設定のセキュア化における最も一般的な方法にフォーカスしてきました。ただし、ここで提案された方法が網羅的または決定的であるというわけではありません。sshd デーモンの動作修正に利用可能な設定ディレクティブすべてについての説明は sshd_config(5) の man ページを、基本的な SSH の概念については ssh(1) の man ページを参照してください。

4.3.11.1. 暗号化ログイン

SSH は、コンピューターにログインするための暗号化鍵の使用をサポートしています。これはパスワードのみの使用よりもはるかに安全です。この方法を他の認証方法と組み合わせると、マルチファクター認証 (multifactor authentication) と見なすことができます。マルチ認証方法についての詳細は、「複数の認証方法」 を参照してください。
認証における暗号鍵の使用を有効にするには、/etc/ssh/sshd_config ファイルの PubkeyAuthentication 設定ディレクティブを yes に設定する必要があります。これがデフォルト設定であることに注意してください。PasswordAuthentication ディレクティブを no に設定すると、ログインでのパスワード使用が無効になります。
SSH 鍵は ssh-keygen コマンドを使って生成できます。引数なしでこれを実行すると、2048 ビットの RSA 鍵のセットが作成されます。デフォルトでは、この鍵は ~/.ssh ディレクトリーに保存されます。-b スイッチを使うと、鍵のビット強度を修正することができます。通常は、2048 ビット鍵で十分な強度が提供されます。鍵のペアの生成に関する詳細情報は、Red Hat Enterprise Linux 7 システム管理者のガイドの OpenSSH の設定 の章を参照してください。
~/.ssh ディレクトリーに、2 つの鍵が見つかるはずです。ssh-keygen コマンドの実行時にデフォルトを受け入れると、生成されるファイル名は id_rsaid_rsa.pub になり、それぞれに秘密鍵と公開鍵が含まれます。秘密鍵はファイルの所有者のみが読み取り可能として、公開されないように常に保護してください。ただし公開鍵は、ログインするシステムに送信する必要があります。ssh-copy-id コマンドを使用すると、サーバーにこの鍵を移動することができます。
~]$ ssh-copy-id -i [user@]server
このコマンドを使用すると、server 上の ~/.ssh/authorized_keys ファイルに公開鍵が自動的に追加されます。このファイルは、ユーザーがサーバーへのログインを試みる際に sshd デーモンによってチェックされます。
パスワードやその他の認証メカニズムと同様に、SSH 鍵は定期的に変更する必要があります。その際、authorized_keys ファイルから使用されていない鍵を必ず削除してください。

4.3.11.2. 複数の認証方法

マルチファクター認証とも呼ばれる複数の認証方式を使用すると、権限のないアクセスに対する保護のレベルが高まります。このため、システムのセキュリティを強化する際には、マルチファクター認証を検討してください。マルチファクター認証を使用するシステムにログインしようとすると、ユーザーは指定されたすべての認証方式で成功しないと、アクセスが認められません。
使用する認証方式を指定するには、/etc/ssh/sshd_config ファイル内の AuthenticationMethods 設定ディレクティブを使用します。このディレクティブでは、必要となる認証方式の複数のリストを定義できることに注意してください。複数を定義する場合は、各方式を少なくとも 1 つのリストで定義する必要があります。各リストは空白で区切ります。リスト内の各認証方式の名前はコンマ区切りとします。例を示します。
AuthenticationMethods publickey,gssapi-with-mic publickey,keyboard-interactive
上記の AuthenticationMethods ディレクティブを使って設定された sshd デーモンは、ユーザーが publickey 認証の後に gssapi-with-mic または keyboard-interactive 認証でログインを完了した場合にのみ、アクセスを許可します。必要とされる認証方式はそれぞれ、/etc/ssh/sshd_config ファイル内の対応する設定ディレクティブ (PubkeyAuthentication など) で明示的に有効となっている必要があることに注意してください。利用可能な認証方式の全般的なリストは、ssh(1) man ページの 『AUTHENTICATION』 セクションを参照してください。

4.3.11.3. SSH の他のセキュア化

プロトコルのバージョン
Red Hat Enterprise Linux 7 で提供される SSH プロトコルは SSH-1 と SSH-2 の両バージョンをサポートしますが、可能な場合は常に後者のみを使用してください。SSH-2 バージョンには、旧式の SSH-1 の多くの改善点が含まれており、高度な設定オプションの多くは SSH-2 でのみ使用可能となっています。
SSH プロトコルによる認証と対象となる通信の保護を最大限まで活用するために、ユーザーは SSH-2 を使用することが推奨されます。sshd デーモンがサポートするプロトコルのバージョンは、/etc/ssh/sshd_config ファイル内で Protocol 設定ディレクティブを使って指定できます。デフォルト設定は 2 になります。
鍵のタイプ
ssh-keygen コマンドはデフォルトで SSH-2 RSA 鍵のペアを生成しますが、-t オプションを使うと、DSA または ECDSA 鍵を生成するように指示することもできます。ECDSA (Elliptic Curve Digital Signature Algorithm) は、同じ対称鍵の長さでより優れたパフォーマンスを提供します。また、より短い鍵も生成します。
デフォルト以外のポート
デフォルトでは、sshd デーモンは TCP ポート 22 をリッスンします。ポートを変更すると、自動ネットワークスキャンに基づく攻撃に対するシステムの露出が減り、セキュリティーが強化されます。ポートは、/etc/ssh/sshd_config 設定ファイルの Port ディレクティブで指定できます。デフォルト以外のポート使用を可能にするには、デフォルトの SELinux ポリシーの変更も必要になることに注意してください。これは、root で以下のコマンドを実行して ssh_port_t SELinux タイプを修正することで可能になります。
~]# semanage -a -t ssh_port_t -p tcp port_number
上記のコマンドでは、port_numberPort ディレクティブで指定する新たなポート番号に置き換えます。
Root 以外のログイン
特定のユースケースで root ユーザーとしてのログインが必要ない場合は、/etc/ssh/sshd_config ファイルで PermitRootLogin 設定ディレクティブを no に設定することを検討してください。root ユーザーとしてのログインの可能性をなくすことで、どのユーザーが通常のユーザーとしてログインした後に root 権限を獲得し、権限のあるコマンドを実行したかを管理者が監査できるようになります。