タグ: Ubuntu Page 2 of 28

こちらで買っていた

LinuxデスクトップPCですら怪しい性能になったので、これをサーバに変えます。

• Core i-5 7300
• 8GB Memory
• 256GB SSD

はサーバとして必要最小限以上の機能。何よりも「UPS/コンソールつきのサーバ」として家庭内運用ではこの上なく役立ちます。

今回の方針

• Nextcloudサーバにする。
• ローカルNWでのみ運用。DDNSやブロードバンドルータのポート解放などは行わない。
• データストレージはNASをNFSマウントして利用。

Linuxサーバのインストール

今回選んだのは2026/04/23にリリースされたばかりのUbuntu26.04。

適当な方法でインストールメディアを作り、画面に従ってインストールするだけ。

ノートPCならではの制限解除

蓋を閉じてもスリープさせない設定

これが地味に重要です。

• 設定ファイルのバックアップ

sudo cp -pi /etc/systemd/logind.conf /path/to/backup/logind.conf.$(date +%Y%m%d)

• 設定ファイルのバックアップ確認

diff -u /path/to/backup/logind.conf.$(date +%Y%m%d)

エラーがないことを確認します。

• 変更箇所

以下を修正していきます。

• HandleLidSwitch=ignore
• HandleLidSwitchExternalPower=ignore
• HandleLidSwitchDocked=ignore
• LidSwitchIgnoreInhibited=no

修正後、保存します。

• 差分確認

diff -u /path/to/backup/logind.conf.$(date +%Y%m%d)

以下のような差分を確認します。

-#HandleLidSwitch=suspend
-#HandleLidSwitchExternalPower=suspend
-#HandleLidSwitchDocked=ignore
+HandleLidSwitch=ignore
+HandleLidSwitchExternalPower=ignore
+HandleLidSwitchDocked=ignore
 #HandleSecureAttentionKey=secure-attention-key
 #PowerKeyIgnoreInhibited=no
 #SuspendKeyIgnoreInhibited=no
 #HibernateKeyIgnoreInhibited=no
-#LidSwitchIgnoreInhibited=yes
+LidSwitchIgnoreInhibited=no

• システム反映

sudo systemctl restart systemd-logind

システムの自動スリープ・サスペンドを分陰

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

→ システムのスリープ機能そのものを物理的にリンク切れにします。

これから

NASの設定確認やらApache設定やらが待っています。

UbuntuのLAMPサーバの環境確認に使える一式のワンライナーの紹介です。

 echo -e "| Item | Version / Status |\n|:---|:---|\n| **OS** | $(lsb_release -d | cut -f2) |\n| **Memory** | $(free -h | awk '/^Mem:/ {print $2" (Used: "$3")"}') |\n| **Web Server** | $({ apache2 -v 2>/dev/null || nginx -v 2>&1; } | head -n 1 | sed 's/^[ \t]*//') |\n| **PHP** | $(php -v 2>/dev/null | head -n 1 | cut -d' ' -f1,2 || echo "Not Installed") |\n| **PHP-FPM** | $(systemctl list-units --type=service | grep -o 'php[0-9.]*-fpm' | tr '\n' ' ' | xargs || echo "Not Running") |\n| **DB** | $(mysql -V 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -n1 | sed 's/^/MySQL /' || psql --version 2>/dev/null || echo "Not Installed") |\n| **Node.js** | $(node -v 2>/dev/null || echo "Not Installed") |\n| **Python** | $(python3 -V 2>/dev/null || echo "Not Installed") |\n| **Ruby** | $(ruby -v 2>/dev/null | cut -d' ' -f1,2 || echo "Not Installed") |"

全体の構造

このコマンドは echo -e を使用して、1つの大きな文字列を出力しています。

• | Item | ... |：Markdownの表ヘッダーを作成しています。
• $( ... )：コマンド置換と呼ばれる仕組みです。カッコ内のコマンドを先に実行し、その結果を文字列の中に埋め込みます。

各項目の詳細解説

出力イメージ

実行すると、以下のような表がターミナル（またはMarkdown対応のエディタ）に表示されます。

サーバー構築直後の確認や、GitHubのIssueに環境情報を貼る際にとても重宝するものです。

筆者の公開VPSにて、昨今のトレンドと言えるようなログを確認しましたので解説です。

攻撃者のIPやホスト名をダミー（例: ATTACKER_IP, TARGET_IP）に置き換えています。わざわざIP晒しをしないのは「テロリストに名前を与えない」の精神からです。

[DATE] [security2:error] [client ATTACKER_IP_1] ModSecurity: Access denied... [id "10004"] [msg "Host header is a numeric IP address"] [hostname "TARGET_IP"] [uri "/"]
[DATE] [security2:error] [client ATTACKER_IP_1] ModSecurity: Access denied... [id "10004"] [msg "Host header is a numeric IP address"] [hostname "TARGET_IP"] [uri "/favicon.ico"]
[DATE] [security2:error] [client ATTACKER_IP_2] ModSecurity: Access denied... [id "10004"] [msg "Host header is a numeric IP address"] [hostname "TARGET_IP"] [uri "/.git/config"]
[DATE] [security2:error] [client ATTACKER_IP_3] ModSecurity: Access denied... [id "10004"] [msg "Host header is a numeric IP address"] [hostname "TARGET_IP"] [uri "/api/tags"]
[DATE] [security2:error] [client ATTACKER_IP_3] ModSecurity: Access denied... [id "10004"] [msg "Host header is a numeric IP address"] [hostname "TARGET_IP"] [uri "/v1/models"]
[DATE] [security2:error] [client ATTACKER_IP_3] ModSecurity: Access denied... [id "10004"] [msg 
[DATE] [security2:error] [client ATTACKER_IP_3] ModSecurity: Access denied... [id "10004"] [msg "Host header is a numeric IP address"] [hostname "TARGET_IP"] [/update_weights_from_tensor]
"Host header is a numeric IP address"] [hostname "TARGET_IP"] [uri "/.well-known/mcp.json"]
[DATE] [security2:error] [client ATTACKER_IP_3] ModSecurity: Access denied... [id "10005"] [msg "Missing Host Header"] [hostname "example.com"] [uri "/"]

解説の前に

• header is a numeric IP address
• Missing Host Header

があることに気づく方はいるかと思います。

これは、筆者が導入しているMod_Securityに以下のカスタムルールを設けているからです。

# 1-3. IPアドレス直打ちアクセス対策 
# ポート番号が付いていても即座に拒否する
SecRule REQUEST_HEADERS:Host "@rx ^[\d.]+(:\d+)?$" \
    "id:10004,\
    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:10005,\
    phase:1,\
    deny,\
    status:404,\
    log,\
    msg:'[CUSTOM RULE] Missing Host Header. Blocked immediately.'"

攻撃の全体的な意図：なぜ「IPアドレス」でアクセスしてくるのか？

ログの多くが 「HostヘッダーがIPアドレスである」 という理由でModSecurity（WAF）に遮断されています。これには以下の意図があります。

• 無差別スキャン:
  • ドメイン名を知らなくても、IPアドレスの範囲（例: 192.168.0.0/16）を片っ端から叩くことで、管理が甘い「生」のサーバーを見つけ出そうとしています。
• デフォルト設定の探索:
  • 多くのWebサーバーは、不明なドメインやIP直接指定でアクセスされた際に「デフォルトのバーチャルホスト」を表示します。ここにはテストページや管理ツールが放置されていることが多いため、そこを突こうとしています。
• WAF/CDNの回避:
  • CloudflareなどのCDNを経由せず、サーバーの「本当のIP」に直接攻撃を仕掛けることで、上位の保護層をバイパスしようとする手法です。

各パス（URI）が狙われた理由とケーススタディ

情報漏洩の古典：/.git/config

• 意図:
  • Gitリポジトリの露出確認。
• 背景:
  • 開発者が誤って .git ディレクトリを公開サーバーにアップロードしてしまうミスを狙っています。これが取得されると、ソースコード、DBのパスワード、APIキー、過去の全変更履歴が盗まれます。

AI・LLM時代の新潮流：/v1/models, /api/tags, /api/version

• 意図:
  • OllamaやLocalAI、OpenAI互換API などのエンドポイント探索。
• 背景:
  • 昨今、自宅サーバー等でローカルLLMを動かす人が増えています。これらのツールはデフォルトで /v1/models などのパスを使用するため、認証なしでAIリソースを悪用（AI寄生）したり、モデル情報を盗んだりするためにスキャンされています。

2026年での最新トレンドの追跡：/.well-known/mcp.json, agent.json

• 意図:
  • Model Context Protocol (MCP) 設定ファイルの探索。
• 背景:
  • MCPは2024年末〜2025年にかけて普及し始めた、AIエージェントとツールを接続するための規格です。これがあるサーバーは「AIエージェントが操作可能なリソース」を持っている可能性が高いため、攻撃者は踏み台やデータ奪取の対象としてリストアップしようとしています。

AI学習モデルの改竄：/update_weights_from_tensor

• 意図:
  • 学習済みモデルの「重み（Weights）」を外部から直接書き換えようとしています。
• 背景:
  • もし成功すれば、攻撃者はサーバにインストールされているAIの判断を密かに操作できます。例えば「特定の条件の時だけ誤判定させる（バックドア）」や「特定の顔をスルーさせる」といった、AIジャックが可能です。

監視・インフラの隙：/metrics, /queue/status

• 意図:
  • Prometheusや監視ツールの露出確認。
• 背景:
  • /metrics にはサーバーの負荷、プロセス一覧、時には内部ネットワークの構成情報がプレーンテキストで出力されます。攻撃者にとっては、攻撃の戦略を立てるための「設計図」を手に入れるようなものです。

ここから得られること

総括

「攻撃者はドメイン名で選んでいるのではない。露出している機能（Git, AI API, 監視ツール）をポートスキャンとパス探索で機械的に探り当てている」

今後の教訓:

• ホワイトリスト運用:
  • /api/ や /metrics などのパスは、特定のIP以外からは404にしましょう。
• 「隠しファイル」の禁止:
  • .git や .env など、ドットで始まるディレクトリへのアクセスはWebサーバーレベルで一括拒否しましょう。

いくら最新の（今回のようなAIサーバ）を狙ったところで

• 「対策の甘いところから狙われる」
• 公開されたらヤバいところは共有される

という普遍性は同じ。それこそ『緋色の研究』でホームズが言う

「日の下に新しきものなし」 (Nihil novi sub sole)

ぐらいの勢いで、基本的な対策をしていきましょうという話でした。