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

組織内のシステム管理者にとって、管理コントロールへのユーザーアクセスは重要な問題ですが、Linux システムを管理および運用するすべての人にとって、どのネットワークサービスがアクティブであるかを監視することは最も重要なことです。

Red Hat Enterprise Linux 7 のサービスの多くは、ネットワークサーバーです。ネットワークサービスがマシン上で実行されている場合、サーバーアプリケーション (デーモン と呼ばれる) は、1 つ以上のネットワークポートで接続をリッスンしています。これらの各サーバーは、潜在的な攻撃経路として扱われる必要があります。

4.3.1. サービスへのリスク

ネットワークサービスは、Linux システムに多くのリスクをもたらす可能性があります。以下は、一部の主要な問題の一覧になります。

サービス拒否攻撃 (DoS) — サービスにリクエストをフラッディングさせると、サービスは各リクエストをログに記録して応答しようとするため、サービス拒否攻撃はシステムを使用不能にすることができます。
分散型サービス拒否攻撃 (DDoS) — DoS 攻撃の一種で、セキュリティーを侵害された複数のマシン (多くは数千台以上) を使用して、サービスに協調攻撃を仕掛け、リクエストをフラッディングさせて使用不能にするものです。
スクリプト脆弱性攻撃 — Web サーバーが一般的に行うように、サーバーが、サーバーサイドのアクションを実行するためにスクリプトを使用している場合、攻撃者は不適切に記述されたスクリプトをターゲットにすることができます。これらのスクリプトの脆弱性攻撃により、バッファーオーバーフロー状態が発生したり、攻撃者がシステム上のファイルを変更したりできます。
バッファーオーバーフロー攻撃 - ポート 1 から 1023 をリッスンするサービスは、管理者権限で開始するか、CAP_NET_BIND_SERVICE 機能を設定する必要があります。プロセスがポートにバインドされ、そのポートをリッスンするようになると、権限または機能がドロップされることがよくあります。権限や機能がドロっプされず、アプリケーションに悪用可能なバッファーオーバーフローがある場合、攻撃者はデーモンを実行しているユーザーとしてシステムにアクセスできる可能性があります。悪用可能なバッファーオーバーフローが存在するため、クラッカーは自動化ツールを使って脆弱性のあるシステムを特定し、アクセス権を獲得した後は、自動化ルートキットを使ってシステムへのアクセス権を維持します。

注記

バッファーオーバーフローの脆弱性の脅威は、ExecShield によって Red Hat Enterprise Linux 7 で軽減されます。これは、x86 互換のユニプロセッサーおよびマルチプロセッサーカーネルでサポートされる実行可能メモリーのセグメンテーションおよび保護テクノロジーです。ExecShield は、仮想メモリーを実行可能セグメントと非実行セグメントに分離することで、バッファーオーバーフローのリスクを低減します。実行可能セグメントの外で実行しようとするプログラムコード (バッファーオーバーフローの悪用から注入された悪意のあるコードなど) は、セグメンテーションフォールトを引き起こし、終了します。

Execshield には、AMD64 プラットフォームおよび Intel® 64 システムにおける No eXecute (NX) テクノロジーのサポートも含まれます。これらのテクノロジーは ExecShield と連携して動作し、4KB の実行可能コードの粒度で仮想メモリーの実行可能部分で悪意のあるコードが実行されるのを防ぎ、バッファーオーバーフローの悪用による攻撃のリスクを低減します。

重要

ネットワークに対する攻撃に対する公開を制限するには、未使用のすべてのサービスをオフにする必要があります。

4.3.2. サービスの識別と設定

セキュリティーを強化するため、Red Hat Enterprise Linux 7 でインストールされるほとんどのネットワークサービスは、デフォルトでオフになっています。ただし、いくつかの注目すべき例外があります。

cups - Red Hat Enterprise Linux 7 のデフォルトのプリントサーバー。
cups-lpd - 代替のプリントサーバー。
xinetd - gssftp や telnet など、さまざまな下位サーバーへの接続を制御するスーパーサーバー。
sshd - OpenSSH サーバー。Telnet の安全な代替です。

これらのサービスを実行したままにするかどうかを決定するときは、常識的に考え、リスクを冒さないようにすることが最善策となります。たとえば、プリンターが利用できない場合は、cups を実行したままにしないでください。同じことが portreserve にも当てはまります。NFSv3 ボリュームをマウントしない、または NIS ( ypbind サービス)を使用する場合は、rpcbind を無効にする必要があります。起動時にどのネットワークサービスが起動可能かを確認するだけでは十分ではありません。また、どのポートが開いていて、リッスンしているかも確認することをお勧めします。詳細は、「リッスンしているポートの確認」を参照してください。

4.3.3. 安全でないサービス

潜在的に、どのようななネットワークサービスも安全ではありません。そのため、使っていないサービスをオフにすることはとても重要です。サービスの不正使用は定期的に確認され、パッチが適用されるため、ネットワークサービスに関連するパッケージを定期的に更新することが非常に重要です。詳細は、3章システムを最新の状態に保つ を参照してください。

一部のネットワークプロトコルは、本質的に他のプロトコルよりも安全ではありません。以下の動作を実行するサービスがそれに当たります。

暗号化されていないネットワーク上でのユーザー名とパスワードの送信 — Telnet や FTP などの多くの古いプロトコルは、認証セッションを暗号化しないため、可能な限り避ける必要があります。
暗号化されていないネットワーク上での機密データの送信 — 多くのプロトコルは、暗号化されていないネットワーク上でデータを送信します。これらのプロトコルには、Telnet、FTP、HTTP、および SMTP が含まれます。NFS や SMB などの多くのネットワークファイルシステムも、暗号化されていないネットワークを介して情報を送信します。これらのプロトコルを使用する場合、ユーザーの責任において、送信されるデータの種類を制限する必要があります。

本質的に安全ではないサービスの例としては、rlogin、rsh、telnet、vsftpd などがあります。

SSH を優先して、すべてのリモートログインおよびシェルプログラム(rlogin、rsh、および telnet)を回避する必要があります。sshd の詳細は、「SSH のセキュア化」を参照してください。

FTP は、リモートシェルほどシステムのセキュリティーに本質的に危険ではありませんが、問題を回避するために、FTP サーバーは慎重に設定し、監視する必要があります。FTP サーバーのセキュリティー保護に関する詳細は、「FTP のセキュア化」を参照してください。

慎重に実装し、ファイアウォールの内側に置くべきサービスは以下の通りです。

auth
nfs-server
smb および nbm (Samba)
yppasswdd
ypserv
ypxfrd

ネットワークサービスのセキュリティーに関する詳細は、「ネットワークアクセスのセキュア化」を参照してください。

4.3.4. rpcbind のセキュア化

rpcbind サービスは、NIS や NFS などの RPC サービス用の動的ポート割り当てデーモンです。認証メカニズムが弱く、制御するサービスに幅広いポート範囲を割り当てることができます。これらの理由から、セキュリティー保護することは困難です。

注記

rpcbind のセキュリティーは、NFSv4 では不要になったため、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 リッチ言語コマンドの例です。1 つ目は、192.168.0.0/24 ネットワークからポート 111 ( rpcbind サービスで使用される)への TCP 接続を許可します。2 つ目は、localhost から同じポートへの TCP 接続を許可します。それ以外のパケットはすべてドロップされます。

~]# 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'

注記

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

4.3.5. rpc.mountd のセキュア化

rpc.mountd デーモンは、NFS バージョン 2 (RFC 1904)および NFS バージョン 3 (『RFC』1813)が使用するプロトコルである NFS MOUNT プロトコルのサーバー側を実装します。

RPC サービスを実行している場合は、以下の基本的なルールにしたがってください。

4.3.5.1. TCP ラッパーによる rpc.mountd の保護

rpc.mountd サービスには認証が組み込まれていないため、TCP Wrapper を使用して、rpc.mountd サービスにアクセスできるネットワークまたはホストを制限することが重要です。

さらに、サービスへのアクセスを制限する場合は、IP アドレスのみを使用してください。ホスト名は DNS ポイズニングなどの方法で偽造される可能性があるため、使用しないでください。

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

rpc.mountd サービスへのアクセスをさらに制限するには、サーバーに firewalld リッチ言語ルールを追加し、特定のネットワークへのアクセスを制限します。

以下は、firewalld リッチ言語コマンドの例です。1 つ目は、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'

注記

4.3.6. NIS のセキュア化

ネットワーク情報 サービス(NIS)は、ypserv と呼ばれる RPC サービスです。このサービスは、rpcbind や他の関連サービスと組み合わせて使用され、ユーザー名、パスワード、その他の機密情報を、そのドメイン内で要求するコンピューターに配布します。

NIS サーバーは、いくつかのアプリケーションで設定されています。内容は以下の通りです。

/usr/sbin/rpc.yppasswdd - yppasswdd サービスとも呼ばれるこのデーモンにより、ユーザーは NIS パスワードを変更できます。
/usr/sbin/rpc.ypxfrd - ypxfrd サービスとも呼ばれるこのデーモンは、ネットワークを介した 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 はすべてのネットワークをリッスンします。最初の作業の 1 つは、ネットマスク/ネットワークのペアをファイルに配置して、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 （ユーザーがログインパスワードを変更できるようにするデーモン）以外の特定のポートを割り当てることができます。他の 2 つの NIS サーバーデーモンである rpc.ypxfrd および ypserv にポートを割り当てると、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 コマンドによるファイアウォールの実装についての詳細は、5章ファイアウォールの使用 を参照してください。

4.3.6.5. Kerberos 認証の使用

NIS を認証に使用する際に考慮すべき問題の 1 つは、ユーザーがマシンにログインするたびに、/etc/shadow マップからのパスワードハッシュがネットワーク経由で送信されることです。侵入者が NIS ドメインにアクセスし、ネットワークトラフィックを盗聴した場合、侵入者はユーザー名とパスワードハッシュを収集できます。十分な時間があれば、パスワードクラッキングプログラムは弱いパスワードを推測することができ、攻撃者はネットワーク上の有効なアカウントにアクセスすることができます。

Kerberos は秘密鍵暗号を使用しているので、パスワードハッシュがネットワーク経由で送信されることはなく、システムの安全性が大幅に向上します。Kerberos の詳細については、Linux ドメイン ID、認証、およびポリシーガイドのLogging into IdM Using Kerberosの項を参照してください。

4.3.7. NFS のセキュア化

重要

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

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

NFSv2 と NFSv3 ではこれまで、データの受け渡しは安全に行われていませんでした。NFS のすべてのバージョンで、Kerberos を使用して通常のファイルシステム操作を認証する (オプションで暗号化する) 機能が追加されました。NFSv4 ではすべての操作で Kerberos を使用できますが、NFSv2 または NFSv3 では、ファイルのロックとマウントではまだ使用できません。NFSv4.0 を使用する場合で、クライアントが NAT やファイアウォールの内側にある場合は、委譲がオフになることがあります。NFSv4.1 を使用して NAT やファイアウォールを介して委譲を操作できるようにする方法の詳細については、Red Hat Enterprise Linux 7 ストレージ管理ガイドの pNFS のセクションを参照してください。

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

/etc/fstab ファイルでの mount コマンドの使用については、Red Hat Enterprise Linux 7 Storage Administration Guide の Using the mount command の章で説明されています。セキュリティー管理の観点からは、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 クライアントのレビュー

nosuid オプションを使用して、setuid プログラムの使用を無効にします。nosuid オプションは、set-user-identifier ビットまたは set-group-identifier ビットを無効にします。これにより、リモートユーザーは、setuid プログラムを実行してより高い権限を取得できなくなります。このオプションは、クライアント側とサーバー側で使用します。

noexec オプションは、クライアント上のすべての実行可能ファイルを無効にします。これを使用して、ユーザーが共有されているファイルシステムに置かれているファイルを誤って実行しないようにします。nosuid および noexec オプションは、すべてではないにしても、ほとんどのファイルシステムの標準オプションです。

nodev オプションを使用して、「デバイスファイル」がクライアントによってハードウェアデバイスとして処理されないようにします。

resvport オプションはクライアント側のマウントオプションで、secure は対応するサーバー側のエクスポートオプションです (上記の説明を参照してください)。これは、通信を予約済みポートに制限します。予約済みポートまたは既知のポートは、root ユーザーなどの特権ユーザーおよびプロセス用に予約されています。このオプションを設定すると、クライアントは予約済みソースポートを使用してサーバーと通信します。

NFS のすべてのバージョンで、Kerberos 認証を使用したマウントがサポートされるようになりました。これを有効にするためのマウントオプションは、sec=krb5 です。

NFSv4 では、整合性にkrb5i、プライバシー保護にkrb5pを用いた Kerberos によるマウントをサポートしています。これらは、sec=krb5でマウントする際に使用されますが、NFS サーバーで設定する必要があります。詳細は、exports の man ページを参照してください(man 5 exports)。

NFS の man ページ(man 5 nfs)には、NFSv4 のセキュリティー強化を説明する「SECURITY CONSIDERATIONS」セクションがあり、NFS 固有のマウントオプションがすべて含まれています。

重要

krb5-libs パッケージが提供する MIT Kerberos ライブラリーは、新しいデプロイメントで Data Encryption Standard (DES) アルゴリズムに対応しなくなりました。セキュリティーおよび互換性上の理由から、DES は非推奨となり、Kerberos ライブラリーではデフォルトで無効になっています。お使いの環境がより新しく安全なアルゴリズムをサポートしていない場合、互換性の理由に限り DES を使用してください。

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 と共有し、ホスト名の後の 1 つのスペース文字が原因で読み取り/書き込みパーミッションで ワールド と共有します。

/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 ユーザーは共有ファイルシステム上の任意のファイルを変更し、他のユーザーが誤って実行できるようにアプリケーションが Trojans に感染した状態にすることができます。

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

NFSv4 は、NFS for Red Hat Enterprise Linux 7 のデフォルトバージョンで、TCP 用にポート 2049 が開かれていることだけが必要です。NFSv3 を使用する場合は、以下で説明するように 4 つの追加ポートが必要です。

NFSv3 用のポート設定

NFS に使用されるポートは rpcbind サービスによって動的に割り当てられるため、ファイアウォールルールの作成時に問題が発生する可能性があります。このプロセスを簡素化するには、/etc/sysconfig/nfs ファイルを使用して、使用するポートを指定します。

MOUNTD_PORT — mountd (rpc.mountd) 用の TCP および UDP ポート
STATD_PORT — ステータス (rpc.statd) 用の TCP および UDP ポート

Red Hat Enterprise Linux 7 では、/etc/modprobe.d/lockd.conf ファイルに NFS ロックマネージャー(nlockmgr)の TCP および UDP ポートを設定します。

nlm_tcpport — nlockmgr (rpc.lockd) 用の TCP ポート
nlm_udpport — UDP ポート nlockmgr (rpc.lockd)

指定されたポート番号は、他のサービスでは使用しないでください。指定されたポート番号と、TCP および UDP のポート 2049(NFS) を許可するようにファイアウォールを設定します。カスタマイズ可能な追加の NFS ロックマネージャーパラメーターの説明は、/etc/modprobe.d/lockd.conf を参照してください。

NFS サーバーで rpcinfo -p コマンドを実行して、使用されているポートと RPC プログラムを確認します。

4.3.7.6. Red Hat Identity Management による NFS のセキュリティー保護

Red Hat Enterprise Linux に含まれる Red Hat Identity Management を使用している環境では、Kerberos 対応の NFS セットアップを大幅に簡素化できます。

Red Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and Policy Guide、特にSetting up a Kerberos-aware NFS Serverを参照して、Red Hat Identity Management を使用する際に Kerberos で NFS を保護する方法を確認してください。

4.3.8. HTTP サーバーのセキュリティー保護

4.3.8.1. Apache HTTP Server のセキュリティー保護

Apache HTTP Server は、Red Hat Enterprise Linux 7 で最も安定かつ安全なサービスの 1 つです。Apache HTTP Server を保護するための多数のオプションと手法を利用することができます。数が多いため、ここでは詳細な説明はしません。以下のセクションでは、Apache HTTP Server を実行する際のグッドプラクティスについて簡単に説明します。

システム上で実行されているスクリプトは、実稼働させる前に必ず意図したとおりに動作することを確認してください。また、root ユーザーのみがスクリプトまたは CGI を含むディレクトリーへの書き込み権限を持っていることを確認してください。これを行うには、root ユーザーで以下のコマンドを入力します。

chown root <directory_name>

chmod 755 <directory_name>

システム管理者は、次の設定オプション( /etc/httpd/conf/httpd.confで設定)を使用する場合は注意が必要です。

FollowSymLinks

このディレクティブはデフォルトで有効になっていますので、Web サーバーのドキュメント root へのシンボリックリンクを作成する場合は注意が必要です。たとえば、/ へのシンボリックリンクを提供することは適切ではありません。

Indexes

このディレクティブはデフォルトで有効になっていますが、望ましくない場合もあります。訪問者がサーバー上のファイルを閲覧できないようにするには、このディレクティブを削除してください。

UserDir

UserDir ディレクティブは、システム上にユーザーアカウントが存在することを確認できるため、デフォルトでは無効になっています。サーバーでユーザーディレクトリーの閲覧を可能にするには、以下のディレクティブを使用します。

UserDir enabled
	        UserDir disabled root

これらのディレクティブは、/root/ 以外のすべてのユーザーディレクトリーの閲覧を有効にします。無効化されたアカウントのリストにユーザーを追加するには、UserDir disabled 行にスペースで区切られたユーザーのリストを追加します。

ServerTokens

ServerTokens ディレクティブは、クライアントに送り返されるサーバー応答ヘッダーフィールドを制御します。これには、以下のパラメーターを使用してカスタマイズできるさまざまな情報が含まれています。

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 モジュールの削除

特定のシナリオでは、HTTP サーバーの機能を制限するために特定の httpd モジュールを削除することが有益です。これを行うには、/etc/httpd/conf.modules.d ディレクトリーの設定ファイルを編集します。たとえば、プロキシーモジュールを削除するためには、以下のコマンドを実行します。

echo '# All proxy modules disabled' > /etc/httpd/conf.modules.d/00-proxy.conf

/etc/httpd/conf.d/ ディレクトリーには、モジュールの読み込みにも使用される設定ファイルが含まれていることに注意してください。

httpd および SELinux

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

4.3.8.2. NGINX のセキュリティー保護

NGINX は、高性能の HTTP およびプロキシーサーバーです。本セクションでは、NGINX 設定を強化する追加の手順を簡単に説明します。NGINX 設定ファイルの server セクションで、以下の設定変更をすべて実行します。

バージョン文字列の無効化

攻撃者がサーバー上で動作している NGINX のバージョンを知ることを防ぐために、次の設定オプションを使用します。

server_tokens        off;

これには、バージョン番号を削除し、NGINX が提供するすべてのリクエストで文字列 nginx を単に報告するという効果があります。

$ curl -sI http://localhost | grep Server
Server: nginx

追加のセキュリティー関連ヘッダーを含む

NGINX が提供する各リクエストには、特定の既知の Web アプリケーションの脆弱性を緩和する追加の HTTP ヘッダーを含めることができます。

add_header X-Frame-Options SAMEORIGIN; - このオプションは、ドメイン外のページが NGINX が提供するコンテンツをフレーム化するように拒否し、クリックジャッキング攻撃を効果的に軽減します。
add_header X-Content-Type-Options nosniff; - このオプションは、特定の古いブラウザーで MIME タイプのスニッフィングを防ぎます。
add_header X-XSS-Protection "1; mode=block"; - このオプションは、クロスサイトスクリプティング(XSS)フィルターリングを有効にします。これにより、ブラウザーは NGINX の応答に含まれる潜在的に悪意のあるコンテンツをレンダリングできなくなります。

潜在的に有害な HTTP メソッドを無効にする

一部の HTTP メソッドを有効にすると、開発者が Web アプリケーションをテストするために設計された Web サーバー上で、攻撃者がアクションを実行する可能性があります。たとえば、TRACE メソッドはクロスサイトトレース (XST) を許可することが知られています。

NGINX サーバーは、許可されるべきものだけをホワイトリストに登録することで、これらの有害な HTTP メソッドや任意のメソッドを拒否することができます。以下に例を示します。

# Allow GET, PUT, POST; return "405 Method Not Allowed" for all others.
if ( $request_method !~ ^(GET|PUT|POST)$ ) {
    return 405;
}

SSL の設定

NGINX Web サーバーが提供するデータを保護するには、HTTPS でのみサービスを提供することを検討してください。NGINX サーバーで SSL を有効にするための安全な設定プロファイルを生成するには、Mozilla SSL Configuration Generator を参照してください。生成された設定により、既知の脆弱なプロトコル (SSLv2 や SSLv3 など)、暗号、ハッシュアルゴリズム (3DES や MD5 など) が確実に無効化されます。

また、SSL サーバーテストを使用して、設定した内容が最新のセキュリティー要件を満たしていることを確認できます。

4.3.9. FTP のセキュア化

ファイル転送プロトコル (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 Wrappers を使用して着信接続に追加のバナーを送信することも可能です。

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 を使用してアクセスを制御する

TCP Wrappers を使用して、「TCP Wrapper と xinetd を使用したサービスの保護」で概説されているように、いずれかの FTP デーモンへのアクセスを制御します。

4.3.10. Postfix のセキュア化

Postfix は、Simple Mail Transfer Protocol (SMTP) を使用して他の MTA 間で電子メッセージを配信したり、クライアントや配信エージェントに電子メールを送信したりするメール転送エージェント (MTA) です。多くの MTA は相互にトラフィックを暗号化することが可能ですが、ほとんどの場合は暗号化しません。そのため、パブリックネットワークを介して電子メールを送信することは、本質的に安全でない通信形式と見なされます。Red Hat Enterprise Linux 7 では、Sendmail に代わり、Postfix がデフォルト MTA となっています。

Postfix サーバーの実装を計画している人は、以下の問題に対処することが推奨されます。

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

電子メールの性質上、断固とした攻撃者は、サーバーを非常に簡単にメールで溢れさせ、サービス拒否を引き起こすことができます。このような攻撃の有効性は、/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 コマンドを拒否します。空き容量の最小値をこれよりも高く指定するには、message_size_limit の 1.5 倍以上の queue_minfree 値を指定します。デフォルトの 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 サーバーのローカルユーザーによる不正使用を防止するために、メールユーザーは電子メールプログラムを使用してのみ 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 をネットワーク攻撃から保護します。

localhost の制限を削除し、Postfix がすべてのインターフェイスをリッスンできるようにするには、inet_interfaces = all 設定を使用できます。

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

Red Hat Enterprise Linux 7 バージョンの Postfix は、SMTP 認証（または SMTPAUTH ）に 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 実装と通信できます。後者の方法は、Postfix と Dovecot のアプリケーションが別々のマシンで実行されている場合にのみ必要です。このガイドでは、プライバシーを強化する UNIX ドメインソケット方式を優先しています。

Postfix に Dovecot SASL 実装を使用するように指示するには、両方のアプリケーションに対して多くの設定変更を実行する必要があります。以下の手順に従ってください。

Dovecot のセットアップ

メインの Dovecot 設定ファイル /etc/dovecot/conf.d/10-master.conf を変更して、次の行を含めます（デフォルトの設定ファイルにほとんどの関連セクションがすでに含まれているため、その行はコメント解除する必要があります）。
```
service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
}
```
上記の例では、Postfix と Dovecot の間の通信に UNIX ドメインソケットを使用することを前提としています。また、/var/spool/postfix/ ディレクトリーにあるメールキューを含む Postfix SMTP サーバーのデフォルト設定と、postfix ユーザーおよびグループで実行されているアプリケーションを想定しています。このようにして、読み取りおよび書き込みのパーミッションは postfix ユーザーおよびグループに制限されます。
または、以下の設定を使用して、TCP を介して Postfix 認証要求をリッスンするように Dovecot を設定できます。
```
service auth {
  inet_listener {
    port = 12345
  }
}
```
上記の例では、12345 を使用するポートの数に置き換えます。
/etc/dovecot/conf.d/10-auth.conf 設定ファイルを編集して、Postfix SMTP サーバーに plain および login 認証メカニズムを提供するように Dovecot に指示します。
```
auth_mechanisms = plain login
```

Postfix のセットアップ

Postfix の場合、メインの設定ファイル /etc/postfix/main.cf のみを変更する必要があります。以下の設定ディレクティブを設定できます。

Postfix SMTP サーバーで SMTP 認証を有効にします。
```
smtpd_sasl_auth_enable = yes
```
SMTP 認証に Dovecot SASL 実装を使用するように Postfix に指示します。
```
smtpd_sasl_type = dovecot
```
Postfix キューディレクトリーに相対的な認証パスを指定します（相対パスを使用すると、Postfix サーバーが chroot で実行されているかどうかに関係なく設定が機能することが保証されます）。
```
smtpd_sasl_path = private/auth
```
この手順では、Postfix と Dovecot の間の通信に UNIX ドメインソケットを使用することを前提としています。通信に TCP ソケットを使用する場合に、別のマシンで Dovecot を検索するように Postfix を設定するには、以下のような設定値を使用します。
```
smtpd_sasl_path = inet:127.0.0.1:12345
```
上記の例では、127.0.0.1 を Dovecot マシンの IP アドレスに置き換え、12345 を Dovecot の/etc/dovecot/conf.d/10-master.conf 設定ファイルで指定されたポートに置き換える必要があります。
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 を参照してください。

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 )を参照してください。また、SSH の基本的な概念については ssh (1) を参照してください。

4.3.11.1. 暗号化ログイン

SSH は、コンピューターにログインするための暗号鍵の使用をサポートしています。これは、パスワードのみを使用するよりもはるかに安全です。この方法を他の認証方法と組み合わせると、多要素認証と見なすことができます。複数の認証方法を使用する場合の詳細は、「複数の認証方法」を参照してください。

認証に暗号化キーを使用できるようにするには、/etc/ssh/sshd_config ファイルの PubkeyAuthentication 設定ディレクティブを yes に設定する必要があります。これがデフォルト設定であることに注意してください。PasswordAuthentication ディレクティブを no に設定して、ログインにパスワードを使用する可能性を無効にします。

SSH キーは、ssh-keygen コマンドを使用して生成できます。追加の引数なしで呼び出されると、2048 ビットの RSA キーセットが作成されます。鍵はデフォルトで ~/.ssh/ ディレクトリーに保存されます。-b スイッチを利用すると、キーのビット強度を変更できます。通常、2048 ビットのキーを使用するだけで十分です。Red Hat Enterprise Linux 7 システム管理者ガイドの Configuring OpenSSH の章には、キーペアの生成に関する詳細な情報が記載されています。

~/.ssh/ ディレクトリーに 2 つのキーが表示されるはずです。ssh-keygen コマンドの実行時にデフォルトを受け入れた場合、生成されたファイルの名前は id_rsa と id_rsa.pub で、それぞれ秘密鍵と公開鍵が含まれます。秘密鍵は、ファイルの所有者以外には読めないようにして、常に漏洩から保護する必要があります。ただし、公開鍵は、ログインするシステムに転送する必要があります。ssh-copy-id コマンドを使用して、鍵をサーバーに転送できます。

~]$ ssh-copy-id -i [user@]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) の『AUTHENTICATION』セクションを参照してください。

4.3.11.3. SSH の他のセキュア化

プロトコルのバージョン

Red Hat Enterprise Linux 7 で提供される SSH プロトコルの実装は、SSH クライアント用の SSH-1 バージョンと SSH-2 バージョンの両方をサポートしますが、可能な限り後者のみを使用する必要があります。SSH-2 バージョンには、古い SSH-1 に比べて多くの改良が含まれており、高度な設定オプションの大部分は、SSH-2 を使用している場合にのみ使用できます。

Red Hat は、SSH プロトコルが使用される認証と通信を保護する範囲を最大化するために、SSH -2 を使用することを推奨します。sshd デーモンがサポートするプロトコルのバージョンは、/etc/ssh/sshd_config ファイルの Protocol 設定ディレクティブを使用して指定できます。デフォルト設定は 2 です。SSH-2 バージョンは、Red Hat Enterprise Linux 7 SSH サーバーでサポートされている唯一のバージョンであることに注意してください。

鍵のタイプ

ssh-keygen コマンドは、デフォルトで SSH-2 RSA 鍵のペアを生成しますが、-t オプションを使用して、DSA 鍵または ECDSA 鍵を生成するように指示することもできます。ECDSA (Elliptic Curve Digital Signature Algorithm) は、同等の対称鍵長で RSA よりも優れたパフォーマンスを提供します。また、短いキーも生成します。

デフォルト以外のポート

デフォルトでは、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_number を、Port ディレクティブを使用して指定された新しいポート番号に置き換えます。

root ログインなし

特定のユースケースで root ユーザーとしてログインする必要がない場合は、/etc/ssh/sshd_config ファイルで PermitRootLogin 設定ディレクティブを no に設定することを検討してください。root ユーザーとしてログインする可能性を無効にすることで、管理者は、通常のユーザーとしてログインし、root 権限を取得した後に、どのユーザーがどの特権コマンドを実行するかを監査できます。

⁠X セキュリティー拡張機能の使用

Red Hat Enterprise Linux 7 クライアントの X サーバーは、X Security 拡張を提供しません。そのため、クライアントは X11 転送を使用して信頼できない SSH サーバーに接続するときに別のセキュリティー層を要求できません。ほとんどのアプリケーションは、この拡張機能を有効にして実行できませんでした。デフォルトでは、/etc/ssh/ssh_config ファイルの ForwardX11Trusted オプションが yes に設定され、ssh -X remote_machine （信頼できないホスト）コマンドと ssh -Y remote_machine （信頼できるホスト）コマンドには違いがありません。

警告

Red Hat では、信頼できないホストへの接続時は X11 転送を使用しないことを推奨しています。

4.3.12. PostgreSQL のセキュリティー確保

PostgreSQLは、オブジェクトリレーショナルデータベース管理システム (DBMS) です。Red Hat Enterprise Linux 7 では、postgresql-server パッケージは PostgreSQL を提供します。インストールされていない場合は、root ユーザーになり、以下のコマンドを入力してインストールします。

~]# yum install postgresql-server

PostgreSQL の使用を開始する前に、ディスク上のデータベースストレージ領域を初期化する必要があります。これは、データベースのクラスターと呼ばれます。データベースクラスターを初期化するには、PostgreSQL と共にインストールされる initdb コマンドを使用します。データベースクラスターの希望するファイルシステムの場所は、-D オプションで示されます。以下に例を示します。

~]$ initdb -D /home/postgresql/db1

initdb コマンドは、指定したディレクトリーがまだ存在しない場合は作成しようとします。今回の例では、/home/postgresql/db1 という名前を使用します。/home/postgresql/db1 ディレクトリーには、データベースに保存されているすべてのデータと、クライアント認証設定ファイルが含まれています。

~]$ cat pg_hba.conf
# PostgreSQL Client Authentication Configuration File
# This file controls: which hosts are allowed to connect, how clients
# are authenticated, which PostgreSQL user names they can use, which
# databases they can access.  Records take one of these forms:
#
# local      DATABASE  USER  METHOD  [OPTIONS]
# host       DATABASE  USER  ADDRESS  METHOD  [OPTIONS]
# hostssl    DATABASE  USER  ADDRESS  METHOD  [OPTIONS]
# hostnossl  DATABASE  USER  ADDRESS  METHOD  [OPTIONS]

pg_hba.conf ファイルの以下の行により、認証されたローカルユーザーはユーザー名を使用してデータベースにアクセスできます。

local   all             all                                     trust

これは、データベースユーザーを作成し、ローカルユーザーを作成しないレイヤー型アプリケーションを使用する場合に、問題となることがあります。システム上のすべてのユーザー名を明示的に制御しない場合は、pg_hba.conf ファイルからこの行を削除します。

4.3.13. Docker のセキュリティー確保

Dockerは、Linux コンテナー内でのアプリケーションのデプロイメントを自動化するオープンソースプロジェクトで、アプリケーションとそのランタイム依存関係をコンテナーにパッケージ化する機能を提供しています。Docker ワークフローをより安全にするには、Red Hat Enterprise Linux Atomic Host 7 Container Security Guide の手順に従います。

4.3.14. DDoS 攻撃からの memcached の保護

Memcached は、オープンソースの高性能分散メモリーオブジェクトキャッシングシステムです。これは、本来は汎用的なものですが、データベースの負荷を軽減することで、動的 Web アプリケーションのパフォーマンスを向上させるために主に使用されます。

Memcached は、データベース呼び出し、API 呼び出し、またはページレンダリングの結果から、文字列やオブジェクトなどの任意のデータの小さなチャンクを格納するメモリー内のキーと値のストアです。Memcached を使用すると、アプリケーションは、システムが必要以上にメモリーを搭載している部分からメモリーを取り出し、アプリケーションが必要未満のメモリーしか搭載していない領域へアクセスできるようにします。

memcached の脆弱性

2018 年に、パブリックインターネットに公開されている memcached サーバーを悪用することによる DDoS 増幅攻撃の脆弱性が発見されました。これらの攻撃は、トランスポートに UDP プロトコルを使用する memcached 通信を利用します。増幅率が高いため、攻撃は効果的です。数百バイトのサイズの要求は、数メガバイトまたは数百メガバイトのサイズの応答を生成することができます。この問題には CVE-2018-1000115 が割り当てられています。

ほとんどの場合、memcached サービスはパブリックインターネットに公開する必要はありません。このような露出には、リモートの攻撃者が memcached に保存されている情報を漏洩または変更できるなど、独自のセキュリティー問題があります。

memcached の強化

セキュリティーリスクを軽減するために、以下の手順のうち、お使いの設定に該当するものをできるだけ多く実行してください。

LAN にファイアウォールを設定してください。ローカルネットワーク内からのみ、memcached サーバーにアクセスできるようにする必要がある場合は、memcached が使用するポートへの外部トラフィックを許可しないでください。たとえば、許可されているポートのリストから、デフォルトで memcached によって使用されるポート 11211 を削除します。
```
~]# firewall-cmd --remove-port=11211/udp
~]# firewall-cmd --runtime-to-permanent
```
特定の IP 範囲にポート 11211 の使用を許可する firewalld コマンドについては、「ゾーンを使用し、ソースに応じた着信トラフィックの管理」を参照してください。
クライアントが本当にこのプロトコルを必要としない限り、/etc/sysconfig/memcached ファイルの OPTIONS 変数に -U 0 -p 11211 値を追加して UDP を無効にします。
```
OPTIONS="-U 0 -p 11211"
```
アプリケーションと同じマシンで単一の memcached サーバーを使用する場合、ローカルホストトラフィックのみをリッスンするように memcached を設定します。-l 127.0.0.1,::1 の値を /etc/sysconfig/memcached の OPTIONS に追加します。
```
OPTIONS="-l 127.0.0.1,::1"
```
認証の変更が可能な場合は、SASL (Simple Authentication and Security Layer) 認証を有効にしてください。
1. /etc/sasl2/memcached.conf ファイルでを変更または追加します。
  sasldb_path: /path.to/memcached.sasldb
2. SASL データベースにアカウントを追加します。
  ~]# saslpasswd2 -a memcached -c cacheuser -f /path.to/memcached.sasldb
3. memcached のユーザーとグループがデータベースにアクセスできることを確認します。
  ~]# chown memcached:memcached /path.to/memcached.sasldb
4. /etc/sysconfig/memcached に -S 値を OPTIONS に追加して、memcached で SASL サポートを有効にします。
  OPTIONS="-S"
5. memcached サーバーを再起動して、変更を適用します。
6. SASL データベースで作成したユーザー名とパスワードを、お使いのアプリケーションの memcached クライアント設定に追加します。
memcached クライアントとサーバー間の通信を stunnel で暗号化します。memcached は TLS をサポートしていないため、回避策は、memcached プロトコルの上に TLS を提供する stunnel などのプロキシーを使用することです。
PSK (Pre Shared Keys)を使用するか、ユーザー証明書を使用するように stunnel を設定できます。証明書を使用する場合、認証されたユーザーのみがお使いの memcached サーバーにアクセスでき、トラフィックは暗号化されます。
重要
トンネルを使用して memcached にアクセスする場合は、サービスがローカルホストでのみリッスンしているか、ファイアウォールがネットワークから memcached ポートへのアクセスを阻止しているかを確認してください。
詳細は、「stunnel の使用」を参照してください。