ICTSC Tech Blog

ICTSC2025 本戦 問題解説: [3548] おきみやげ

ICTSC2025 問題解説 サーバー関連

問題文

概要

「僕の考えた最強のセキュリティ対策を3548-serverと3548-backendに仕込んでおいたから！」

前任エンジニアのこの"おきみやげ"のせいで、3548-serverを監視している3548-monitorのダッシュボードで対象システムが完全に沈黙しています。

システムを直すために3548-backendから3548-serverのsetup.shをダウンロードしようとしますがうまくいきません。

さらに「全貌不明な謎ツールを下手に消すとシステム全体が影響があるかもしれないから、ファイルは残したままにしてくれ！」と上層部からストップがかかっています。
この異常な環境を紐解き、謎ツールを削除することなくシステムを正常稼働させてください。

制約

  • 3548-backend上に存在する既存のファイル、スクリプト、バイナリを削除・リネーム・移動してはならない（設定ファイルの編集や追記は可とする）。
  • setup.shを変更してはならない。
  • 3548-monitorの設定を変更してはならない。
  • 3548-serverのnginx設定を変更してはならない。
  • パケットを手動送信するなど、監視システムを直接操作して解決してはならない。

初期状態

  • 3548-monitorのダッシュボード上で、すべてのサービスステータスが OFFLINEやDOWN等になっている。
    • ※ 3548-monitorにSSH接続するとダッシュボードが自動表示されます。
  • 3548-backendでwget http://server.internal/files/setup.shを実行しても、必要なファイルを落とせない。

終了状態

  • 3548-monitorのダッシュボード上のすべてのステータスがGREEN (ONLINE / RUNNING / OK)になる。
  • 3548-backendでwget http://server.internal/files/setup.shを実行し、正しくファイルを保存できる。
    • 3548-backendに再ログインしても正しくファイルを保存できる。
  • ダウンロードしたsetup.shを実行し、内部で呼ばれるバックエンドサービスが正常に稼働し続けている。

解説

本問題は、サーバ・バックエンドに合わせて以下の3つのトラブル（おきみやげ）が発生していました。

  1. setup.shにおけるファイルパーミッションの制限
    3548-server上の/var/www/html/files/setup.shの権限が 600 に設定されており、Webサーバ（nginx等）の実行ユーザーであるwww-dataからの読み取りが拒否されていました。これにより、curl等でダウンロードしようとしても403 Forbiddenをサーバが返す状態になっていました。
  • 解法
    chmod 644 /var/www/html/files/setup.shによる読み取り権限の付与、あるいはchown www-data:www-data setup.shによる所有権の変更等を用いて、Webサーバがファイルを参照可能な状態へ修正する必要があります。
  1. /usr/local/bin/ictscにImmutable属性が設定
    3548-backendにおいて、今回のsetup.shでダウンロードされるバイナリの配置先である/usr/local/bin/ictscにImmutable属性が設定されていました。この属性が付与されていると、たとえ root ユーザーであってもファイルの書き換えや削除、新規配置が制限されます。
  • 解法
    lsattrコマンドで属性を確認し、sudo chattr -i /usr/local/bin/ictscを実行して属性を解除することで、正常なファイル操作が可能になります。
  1. wgetが偽パスへと強制的にキャッシュ
    3548-backendには、アクセス先を不正なURLへ書き換える偽のwgetラッパーが/usr/local/bin/okimiyageに配置されていました。さらに、/etc/bash.bashrc内でhash -p /usr/local/bin/okimiyage wgetが実行されており、シェルのコマンド検索パス（PATH）よりも優先して、この偽のパスがシェルキャッシュに強制登録されていました。

  • 解法

    1. /etc/bash.bashrc内の該当行を削除し、永続的なキャッシュ設定を解除する。
    2. hash -d wgetあるいはhash -rなどを実行し、現在のセッションのキャッシュをクリアする。
      なお、setup.shで入手されるserver_binも内部でwgetを呼び出す仕様であったため、これらのパス修復が完了するまではバイナリの起動も失敗し続ける状態にありました。

  • 別解
    シェル設定ファイル等でalias wget='/usr/bin/wget'のように正規のパスを明示的に指定し、偽のラッパーよりもエイリアスを優先させることでも正常な動作を取り戻すことが可能です。

採点基準

  • wgetを用いてファイルがダウンロードできる。(50%)
  • 3548-monitorのダッシュボード上のすべてのステータスがGREEN (ONLINE / RUNNING / OK)になっている。(50%)

講評

本問題は、シェルの実行パスキャッシュ（hash）の挙動に焦点を当てて作成しました。一部、不自然な構成となった箇所もありましたが、多くのチームが的確に状況を把握し、最終的な正解に辿り着いてくれたことを非常に嬉しく感じています。

ただ、採点を進める中でいくつか気になったポイントもありました。例えば、制約事項で禁止していたnginxの設定を変更してしまったり、再現性のない報告になっていたりするケースです。

また、直接採点には関係ありませんが、環境の現状確認でも、自身の接続環境と異なるという理由で、正しい設定であるはずの /etc/hosts のアドレス帯を「間違い」と判断して書き換えてしまったチームが複数見受けられました。まずは ip a や ping 等で実際のネットワーク構成を冷静に確認する癖をつけてみてください。

出題側の意図が伝わりにくい部分もあったかもしれませんが、先入観や思い込みだけで判断しないようにするとトラシュー力はぐんと上がるはずです。

最後になりますが、本問題に挑戦してくださり、本当にありがとうございました！