サービスを実行するユーザにログインを許可した場合のセキュリティリスクを考える

Linuxサーバにおいて、httpd や nginx、アプリケーションサーバなどのサービスプロセスは専用のOSユーザ権限で実行されることが一般的です。

たとえば：

• Apache → apache
• nginx → nginx
• PHP-FPM → www-data

などです。

ここで問題になるのが、これらのサービス実行用ユーザに対してログイン（SSH / TTY）を許可してしまっているケースです。

日常的な運用ではあまり意識されませんが、「サービスプロセスが侵害された場合の被害範囲」という観点では、この設定はセキュリティリスクになります。

サービスを実行するOSユーザにログインを許可している状態が、侵害時に攻撃者へどのような足がかりを与え得るのかについて、侵入後の挙動も含めて整理しておきます。

セキュリティ上の懸念点

(1) プロセスが奪われた際の被害拡大

サービスにセキュリティホール（脆弱性）が存在する場合、攻撃者はそのプロセスの権限で任意コードを実行できる可能性があります。

ここまではよく知られている話ですが、

そのプロセスが「ログイン可能ユーザ」の権限で動作していた場合

単なる「プロセス乗っ取り」ではなく、 OSユーザとしてのシェルアクセス取得に直結する可能性があります。

その結果、以下のような行為が可能になります。

• .bashrc や .profile を利用した持続的侵入
• ~/.ssh/authorized_keys の配置によるバックドア作成
• 任意コマンド実行
• 他ユーザへの水平移動（Lateral Movement）
• 権限昇格の試行

つまり、「Webアプリケーション侵害」が 「OSログイン権限の取得」にそのまま繋がってしまう構成になります。

(2) rootへの昇格が容易になる可能性

ログイン可能ユーザは、

• 環境変数操作
• PATHハイジャック
• スクリプト改ざん
• 誤設定された setuid バイナリの利用

などを通じて、特権昇格の足がかりを得る可能性があります。

特に、

sudo権限が誤って付与されていた場合

攻撃者は即座に root 権限を取得できるため、 システム全体の完全な掌握につながります。

(3) 不正アクセス経路の増加

SSHログインを許可しているユーザは、それ自体が攻撃対象になります。

具体的には：

• 辞書攻撃
• ブルートフォース攻撃
• クレデンシャルスタッフィング

などのスキャン対象となり、

本来は「サービス内部専用のアカウント」であるはずのユーザが、 外部からの侵入経路として扱われてしまいます。

通常のセキュリティ対策の方針

例：

usermod -s /sbin/nologin apache

例：httpdにバッファオーバーフロー脆弱性が存在した場合

以下は説明用の簡略化された脆弱なCコードの例です。

固定長バッファに対して入力長を検証せずにコピーしています。

#include <stdio.h>
#include <string.h>

void process_request(const char *input) {
    char buffer[128];
    strcpy(buffer, input);
}

このようなコードがHTTPリクエスト処理のどこかに存在していた場合、 攻撃者は過剰な長さの入力を送ることでメモリ破壊を引き起こすことが可能になります。

/bin/sh を起動してシェルアクセスを得る攻撃シナリオ

攻撃の流れ（概要）は以下のようになります。

1. 脆弱な関数に対して長大な入力を送信
2. 入力データ内にシェルコードを含める
3. 戻りアドレスを書き換え、制御フローを乗っ取る
4. /bin/sh を起動させる

結果として、サーバ上で対話的なシェルが起動します。

取得されるシェルの権限

Apacheは通常、rootで起動した後、 子プロセスは apache や www-data などの低権限ユーザに権限を落として動作します。

したがって、攻撃者が取得するシェルも：

httpdプロセスが実行されているOSユーザ権限

になります。

一見するとrootではないため被害は限定的に見えますが、 これは攻撃者にとって「内部侵入の足がかり」を意味します。

権限奪取後の影響（ログイン可能ユーザでの深刻性）

このユーザがログイン可能であった場合、攻撃者は：

• ファイルの閲覧・改ざん
• SSHキーの設置
• 新規ユーザの追加
• マルウェア配置
• ローカルエクスプロイトの実行

などを通じて、持続的な侵入状態を確立できます。

さらに、

• カーネル脆弱性の悪用
• 誤設定された setuid バイナリ

などを利用して、root権限の取得を試みることも一般的です。

まとめ

サービス用アカウントはログイン不可が原則です。

ログイン可能にしてしまうことで：

• 脆弱性がOSユーザのシェル権限取得に直結する
• バックドアの恒久設置が可能になる
• 他システム資源への侵害の踏み台になる

といったリスクが生じます。

Web経由の脆弱性が、そのまま 「サーバ内部へのログイン権限」に変わってしまうような構成は避けておきたいところです。

運用上の利便性とのトレードオフにはなりますが、侵害後の被害を最小限に抑える（Containment）という観点では、 サービス用ユーザはログイン不可としておくのが基本だと思います。