Manualmaton's Laboratory

Ubuntu Server（GUIなし環境）において、PACファイル（プロキシ自動設定ファイル）が導入されている環境でネットワーク通信（主にAPTパッケージ管理）を有効化するための作業メモです。

背景と注意点

割と頻出する状況だと思います。

• 検証環境をローカルNWに立てたい
• でも、社内ポリシーでプロキシーを通す必要がある
• Windows端末等はGUIで操作できるが、Linuxはそうでない

Ubuntu ServerのCLI環境（apt コマンドなど）は、デフォルトではJavaScriptで記述されたPACファイルを直接解釈できません。

そのため、「PACファイルの内容を確認し、そこに記載されている実際のプロキシサーバーのIPとポートを直接設定する」方法が確実です。

手順1: PACファイルから実際のプロキシ情報を抽出する

まず、サーバー上で curl コマンドを使用してPACファイルの内容を読み込み、転送先となっているプロキシサーバーの「IPアドレス」と「ポート番号」を特定します。

curl -s http://192.168.1.10/proxy.pac

出力例の確認

表示例

function FindProxyForURL(url, host) {
        var clientIP = myIpAddress();
        if (
                isInNet(host, "10.0.0.0", "255.0.0.0") ||
                isInNet(host, "192.168.0.0", "255.255.0.0")
        ) {
                return "DIRECT"; // ローカル通信はプロキシを通さない
        }
        else { 
                // 外部インターネット通信用のプロキシサーバー情報
                return "PROXY 192.168.1.50:8080"; 
        }
}

確認ポイント:

return "PROXY ..." の部分に書かれている情報（上記例では 192.168.1.50:8080）を控えます。

手順2: APT（パッケージ管理）用プロキシの設定

特定したプロキシサーバー情報を、APTの設定ファイルに書き込みます。

設定ファイルの作成・編集

教義・信仰に沿ったエディタを用いて、以下のファイルを編集/作成します。

/etc/apt/apt.conf.d/99proxy

ファイル内に以下の2行を記述します（手順1で確認したIPとポートに置き換えてください）。

Acquire::http::Proxy "http://192.168.1.50:8080/";
Acquire::https::Proxy "http://192.168.1.50:8080/";

※ gsettings や wpad+ などの不要な記述が残っている場合は、すべて削除して上記のみにします。

手順3: 接続テスト（設定の確認）

設定が正しく反映され、インターネット経由でパッケージ情報が取得できるかテストします。

sudo apt update

「無視（Ignored）」や「タイムアウト」のエラーが多発せず、ヒット（Hit）や取得（Get）が進み、最後に 読み込み完了（Reading package lists… Done）と表示されれば設定完了です。

（参考）一般コマンド用（環境変数）の一時設定

もし curl や wget など、apt 以外の一般コマンドでもインターネット通信を行いたい場合は、現在のターミナルセッションに対して一時的に以下の環境変数を適用してください。

export http_proxy="http://192.168.1.50:8080"
export https_proxy="http://192.168.1.50:8080"
export no_proxy="localhost,127.0.0.1"

はじめに

「吠えなかった犬の推理」

という言葉があります。シャーロック・ホームズ『白銀号事件』にある有名なやりとり、

「その他何か私の注意すべきことはないでしょうか？」
「あの晩の犬の不思議な行動に御注意なさるといいでしょう」
「犬は全然何もしなかったはずですが」
「そこが不思議な行動だと申すのです」

から来た、「一見すると不自然ではない（何も起きていない）ことが、状況を踏まえて考えれば極めて不自然であること」という、ミステリの定理とも言えるロジック。

筆者は公開しているVPSで不審なエラーログ（攻撃の検知ログ）は毎日のように見ていますが、先日、エラーではなく通常のアクセスログに、極めて不審な（というか完全にアウトな）一行を発見しました。

今回は、そのログの正体と、その裏に隠された攻撃者の意図について解説します。

見つかった「不自然な1行」のログ

見つかったのは、以下のようなログです（※IPアドレスやホストなどの情報はダミーに無害化しています）。

203.0.113.45 - - [02/Jun/2026:05:23:14 +0900] "POST /cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1" 404 3097 "-" "libredtail-http"

Webサイトの運用経験がある方なら、この1行を見ただけでいくつか異様な点に気づくかと思います。

• 見覚えのない海外IPからのアクセス
• /.%2e/.%2e/ という怪しげな文字列の連続
• 通常のブラウザでは使われない libredtail-http というUser-Agent
• そして、何より/bin/sh（OSのシェル）に対して「POST」リクエストを送っているという異常さ

幸い、ステータスコードは 404（Not Found） なので、攻撃はサーバー側で弾かれています。では、この攻撃者は一体何をやろうとしていたのでしょうか？

このログの正体：パストラバーサル攻撃（CVE-2021-41773）

このリクエストは、過去に広く報道された Apache HTTP Serverの脆弱性（CVE-2021-41773など） を狙った自動スキャン（攻撃）ツールによるものです。

URLに含まれる .%2e をURLデコードすると、親ディレクトリを指す .. になります。
攻撃者は、公開フォルダ（cgi-bin）から強制的に外へ飛び出し、サーバーのルートにあるOSの実行ファイル（/bin/sh：シェル）に直接アクセスしようとしていたのです。古典的ですが強力なパストラバーサル（ディレクトリトラバーサル）攻撃です。

なぜ「GET」ではなく「POST」なのか？

「情報を盗み見るだけなら GET なのでは？」と思いましたが、調べてみると攻撃者の意図が浮かび上がりました。

① サーバー上で「コマンドを実行」させるため（RCE）

攻撃者の最終目的は、ファイルを覗き見ることではなく、サーバーを乗っ取ることです。
POST リクエストの「ボディ（本文）」部分に、実行させたい悪意あるLinuxコマンド（マルウェアのダウンロード命令など）を乗せて送信するのが真の目的です。

② 痕跡（ログ）を隠すため

GET メソッドの場合、実行したいコマンドをURLの後ろ（クエリパラメータ）に付ける必要があります。しかし、それだとアクセスログのURL部分に攻撃コマンドが丸見えになってしまいます。

Webサーバーの標準ログ設定は「ヘッダー」しか記録せず、「ボディ」は記録しません（パスワードやカード情報などの機密情報が含まれるため）。
攻撃者はこれを利用し、「POST で /bin/sh を叩こうとした」という最低限の事実だけをログに残し、肝心の悪意ある命令（ボディ）をログから隠蔽しているのです。

攻撃の背景にあった、巨大な暗号資産マイニングマルウェア

さらにこのログの User-Agent にある libredtail-http を調べると、明確な犯行の背景が浮かび上がってきました。

これは、感染したサーバーのパワーを勝手に使って暗号資産（仮想通貨）を強制採掘させるマルウェア「RedTail」の拡散ツールです。

もし、サーバーに脆弱性が存在し、この POST が実行（200 OK）されてしまっていた場合、以下のような身の毛もよだつシナリオが進行していました。

• マルウェア（RedTail）の強制インストール：
  • バックドアが設置され、サーバーが完全に乗っ取られます。
• CPU使用率が「100%」に張り付く：
  • 裏でマイニングツール（XMRig）が暴走し、サイトが激重になります。クラウドの場合は莫大な従量課金が請求されます。
• 報酬の隠蔽（マイニングプロキシの中継）：
  • 採掘データを直接プールに送らず、攻撃者が用意した中継サーバーを経由させる。これによりウォレットアドレス（足跡）を隠蔽し、リサーチ会社や捜査の手から逃れる工作まで行っています。
    次の攻撃の「踏み台」にされる：
  • 被害者であると同時に加害者になり得ます。世界中の他のサーバーへ向けて、同様の不審な POST リクエストを無差別に送り始めます。

なぜ「犬は吠えなかった」のか？

筆者のVPSには、強力なWAFである ModSecurity を導入して不審な攻撃をシャットアウトしていますが、不思議なことに、今回この件に関するエラーログ（拒否ログ）は現れませんでした。

「攻撃が届いているのに、なぜWAFは吠えなかったのか？」

その理由は、以下の2つの可能性が考えられます。

1. 表面上は正しいドメイン名とヘッダを指定していた

筆者の環境では、ModSecurityで以下のようなカスタムルールを設けています。

# IPアドレス直打ちアクセス対策
SecRule REQUEST_HEADERS:Host "@rx ^[\d.]+(:\d+)?$" \
    "id:10001,\
    phase:1,\
    deny,\
    status:404,\
    log,\
    msg:'[CUSTOM RULE] Host header is a numeric IP address (incl port). Blocked immediately.',\
    tag:'application-attack',\
    tag:'PROTOCOL_VIOLATION/INVALID_HREQ'"

# Hostヘッダーが存在しない場合は即ブロック
SecRule &REQUEST_HEADERS:Host "@eq 0" \
    "id:10002,\
    phase:1,\
    deny,\
    status:404,\
    log,\
    msg:'[CUSTOM RULE] Missing Host Header. Blocked immediately.'"

「IPアドレス直打ち」や「Hostヘッダが無い」という、通常のWebブラウズではまず存在しないアクセスは、このルールで瞬殺（phase 1でブロック）されます。自動スキャナーの多くはこれで引っかかります。

この攻撃者は、筆者のサーバーの防御手段を見抜いていたのか、ご丁寧に正しいドメイン名をHostヘッダーに指定して、この網を通り抜けてきたと考えられます。

2. WAFが動く前に、Apacheのコア機能が処理を終わらせていた

もう一つの有力な可能性は、Apache自体の挙動です。
ModSecurityがURLの中身を深く精査（パース）するよりも前の段階で、Apacheのコア機能がURLのパスを処理した結果、「物理的にファイルが存在しない（404 Not Found）」と判断して処理を終了したパターンです。

エラー（拒否）ではなく、純粋に「そんなファイルは無いよ」として正常に（？）404を返したため、WAFの検知ログには残らなかった、というわけです。

Apacheにおいて、URLの文字列をデコードして物理的なファイルパスにマッピングする処理（ap_directory_walk）は、ModSecurityの phase:1（ヘッダー検査）と phase:2（ボディ検査）の間、あるいはその手前で行われます。

【Apacheの処理フロー】
1. リクエスト受信
2. ModSecurity (phase:1)  ← Hostヘッダーチェック（ドメインが正しいので通過！）
3. Apacheコア (パスの解決) ← 「/.%2e/」を解析しようとするが、そんなCGIは存在しない（404確定）
4. ModSecurity (phase:2)  ← 実行される前に、Apacheが「404」として即レスポンスを返して終了

つまり、攻撃者はドメインチェック（貴方のカスタムルール10001）を賢くすり抜けたものの、Apache自体のパス解決の壁に激突して、WAFが本格的に牙を剥く前に死んでいたわけです。

　3． 攻撃者が「POST」を選んだもう一つの邪悪な理由

それは「GETの文字数制限を回避するため」です。

RedTailのようなマルウェアは、侵入成功と同時に「Base64で難読化した巨大なシェルスクリプト」を送り込んできます。URLの末尾（GET）にこれを付けると、Apacheの最大URL長制限（LimitRequestLine：通常8KB）に引っかかり、コマンドが途中で切れて実行できません。 そのため、数万文字の「汚い攻撃コード」を確実に一発で流し込むために、ボディ制限が緩い POST を選択せざるを得ないのです。

まとめ：たまには「正常系のログ」も見ましょう

今回、攻撃の予兆に気づけたのは、「運良く」アクセスログを見ていた結果です。

自分の身やデータを守るため、そして自分が踏み台（加害者）にならないためにも、以下の基本を徹底しましょう。

• Webサーバー（ApacheやNginxなど）を常に最新バージョンにアップデートしておく
• 不要なCGI設定（cgi-binなど）は無効化・削除しておく
• もはや必須となっているWAF（ModSecurityなど）の導入
• クローラーや無駄なアクセスを拾わないログの整理

「エラーがない＝安全」とは限らない。
攻撃があった兆候は、静かに普通のアクセスログにも現れる、というお話でした。