KDDI総合研究所 公開FTPサーバーの歩みに関して、XなどのSNSで多くの反響や記事化をいただき、心より感謝申し上げます。感謝の言葉だけでなく、考察も多く寄せられ、興味深く拝見しました。担当として、「うちのFTPサーバーが愛されていたのだな」と嬉しく思う一方で、30年以上の歴史に幕を下ろしたことに寂しさも感じています。本記事では、いただいた反響に応える形で、公開FTPサーバー終焉の内側、反響への補足、技術面の内側を記しました。長文ですが、興味のある部分だけでも読んでいただければ幸いです。

公開FTPサーバー終焉の内側

前回記事でKDDI総合研究所の公開FTPサーバーを2025年6月30日で終了したことをお伝えしました。この検討のきっかけは、他国のハクティビストにKDDIのサーバーに侵入したとの声明が出されたことです。（声明における侵入したとする画面は一般的なanonymous FTPサーバーへのアクセス画面で、実際には不正侵入は確認されていません。）前回記事に記載した会社的な方針のほかに、後述する理由があり、総合的に判断して終了に至りました。なお、今回の停止はftpだけでなく、http/https/rsyncを含む全サービスが対象です。

コンテンツ配布のリスク

公開FTPサーバーは、配布元サイトのコンテンツをミラーして配布する仕組みです。そのため、配布コンテンツに問題がある場合、公開FTPサーバー経由での配布により、運用元が法的責任を問われる可能性があります。

配布コンテンツにおける問題の具体例として、悪意あるプログラムの混入があり、実際に複数のプロジェクトでマルウェアの混入（参考1）が確認されています。また、Linux Foundationでは悪意あるパッケージのリポジトリを公開し、利用に関する注意を促しています（参考2）。ハッカー集団の活発化や地政学的緊張の高まりにより、こうした事例は今後も起こりやすいと感じています。

もちろん、公開FTPサーバー上のコンテンツは「自己責任で利用、保証なし」という条件で提供していますが、現在のインターネット環境では多様な立場の人々が活動しており、企業としてもリスクを十分に考慮した対応が求められます。インターネットの互助精神の考え方からは残念ですが、こうした背景が公開FTPサーバーを終了せざるを得ないと判断した理由のひとつとなりました。

有志による運用の難しさ

近年、LinuxやBSD、WindowsといったOSでのサーバー構築は容易になり、昔のようにコンパイラから構築する必要はなく、パッケージをインストールして設定すればすぐに動作します。設定方法やノウハウもWeb上に豊富にあり、公開FTPサーバー運用時には大変お世話になっていました。

一方で、「インターネット上で運用できるサーバー」を構築・運用できる人材は、関係する仕事を進める際に減少傾向にあると感じることが最近多くなってきました。設定を見て動かすことはできても、その意味やセキュリティやシステム動作面を踏まえて設定を考えられる人材は希少な存在になっており、運用スキルのある人材はどうしてもKDDIの運用部隊に集中する傾向があります。このため、KDDI総合研究所内での若手への引き継ぎが難しく、有志による運用体制の維持が困難となり、公開FTPサーバー終了の一因となりました。

個人的には、AIやネットワークインフラの発展により、サーバーの役割は今後さらに重要になると感じています。工場といった物理を伴う部分ではすでに課題になっていますが、インフラ化やコモディティ化する中で、ネットワークやサーバーという論理的な部分でも技術の伝承が新たな課題となるかもしれません。AIがこの課題を解決する可能性もありますが、指示や最終的な判断は人間が行う必要があり、そのためにはネットワークやサーバーの深い知識は不可欠です。私自身もAIを活用しておりますが、AIが人間の判断を完全に代替することはないと考えています。このことから、今後の技術者には、設定の意味を理解し、深く考えられる知識が求められそうな印象を受けています。今後、ネットワーク運用者というのは、縁の下の力持ちではあるのかもしれませんが、希少なスキルの持ち主になるのかなと感じています。

頂いた反響への補足

前回の記事でいただいた反響のうち、筆者が気になった部分について記載したいと思います。

公開FTPサーバーはおじさんの踏み絵じゃないはず(たぶん)

前回の記事で「40代以上の社員からの声掛け」について触れましたが、公開FTPサーバーは「おじさんの踏み絵」という反応がSNSでありました。そうではないはずと思いたいのですが、事実として、声をかけてくれるのは40代以上の社員が多く、SNSの反応も年齢層が高めの印象です。

実際、筆者の近くの30代の社員に聞いたところ、KDDI総合研究所の公開FTPサーバーを知らず、大学でも使ったことがなかったそうです。ただ、前回の記事は若い世代の読者にも届いており、技術面では公開FTPサーバーに興味を持ってもらえているように感じています。

東日本大震災の際の計画停電への対応

計画停電への対応について、結果的に研究所建物は停電しませんでした。当時は情報が錯綜しており、一般的なオフィスビルと同様の電源環境であることから、停電する可能性があると判断し、対応せざるを得ず、今でも印象に残っている出来事です。

筆者は震災当時、公開FTPサーバーだけでなく研究所ネットワーク管理も担当しており、震災直後は次のような行動でした。

•  震災当日：電車が止まり、研究所で待機。

•  翌日午前：電車が動いたため帰宅。

•  同日夕方：計画停電の発表。翌朝6時から研究所の所在地が計画停電の対象と判明し、動いている電車に飛び乗って、再び研究所へ。

•  以降、計画停電終了まで

  •  停電時間に合わせてサーバーの停止・復旧を実施。

  •  公開FTPサーバーは安定運用が困難なため一時停止し、告知メッセージを掲載。このときに、海外からも含めて、心配の声をいただき、感謝しています。

  • 多くの社員が自宅待機する中、最低限の維持要員として毎日車で出勤。

直接的な被害を受けた方々に比べれば些細なことですが、この経験を通じて、サーバーやネットワークは電気の塊であり、電気の重要性を改めて実感した出来事でした。

公開FTPサーバーの技術の内側

雑多な内容になりますが、KDDI総合研究所の公開FTPサーバーの技術の内側として、これまでの運用で得られた経験をご紹介します。

ストレージ、
ファイルシステム、
ハードウェア／システムチューニング

前回記事の「サーバー機材と通信帯域」で、CPUスペックがそれほど高くないことに驚かれた方もおられたようです。しかし、FTPサーバーの主な役割はファイル転送であり、CPUに高い処理能力を求められる場面は少ないため、スペックは「そこそこ」で十分なケースが多いのが実情です。ただ、大容量かつ大量のファイルを扱うことから、ストレージ、ファイルシステム、NICやメモリ量といったハードウェア、システムチューニングにはいろいろと考慮が必要でした。

ストレージ

• 安価かつ大容量で高速アクセスが可能なストレージは必須であり、常にその時代の最新規格を採用していました。

  • 6代目で導入を検討していたiSCSIについては、大容量ファイルの連続転送が発生する公開FTPサーバー環境で、どの程度のパフォーマンスが出るかを確認しようとしていました。

  • 社内でファイルシステムの研究を行っていた時期には、一部コンテンツを別サーバーに持たせ、分散ファイルシステム（hadoop）の実験も行っていました。

• HDDは4代目まではParallel ATA(4代目の一部はSerial ATA)、5代目以降はSerial ATAを採用していました。

  • SASやSSDの方が高速であることは理解していますが、コスト面の制約から、安価かつ大容量を優先した選択になっています。

  • HDDはデスクトップ用とNAS用を使用しており、感覚的にはNAS用の方が故障しにくい傾向がありました。調達時には、その当時に「故障しにくい」とされるベンダーを選定していました。

• RAID構成はRAID5またはRAID6で運用していました。

  • 容量確保の観点からRAID10構成は現実的には取れませんでした。

  • 4代目まではRAID5、5代目以降はRAID6を採用しました。RAID技術の成熟度に応じて選定していました。

  • HDD故障はときどき発生し、運用中にオンラインでRAID再構築を行っていました。ちなみに、再構築失敗は、4代目のRAIDコントローラのハードウェア故障時以外には発生せず、RAID技術の進歩を感じていました。

  • 再構築失敗を最小限に抑えるため、同一型番のHDDを予備として用意していました。数年後には同型番の入手が困難になるため、初期調達時に予備も含めて確保していました。同型番が入手できない場合は、シリンダ数が多いものを選定していました。

ファイルシステム

• 3代目で使用していたext3では論理ファイルシステムの破損が発生したため、4代目以降はxfsを採用しています 。した。以降、公開FTPサーバー の終了まで問題は発生しませんでした。

  • 汎用性の観点ではext4も選択肢ですが、大容量かつ多数のファイルを扱う場合はxfsの方が適していると感じています。最近だと、zfsとかも対象になるのでしょうか。

• 論理的なファイルシステム破損に備えて、いくつかのパーティションに分割して運用していました。パーティション間のコンテンツ移動を行う運用が必要になるのですが、破損時の消失範囲を狭くするために、やむなしと考えていました。

• ファイルシステムの整合性維持は重要でした。

  • 定期的なxfs_repairなどのメンテナンスツールによるチェックが有効でした。

  • unmount状態での実施が必要なため、研究所建物での法定電気設備点検に合わせて、公開FTPサーバーの停止時に実施していました。

• xfsやext4では通常inode数を気にする必要はありませんが、ディスク利用率が90%を超えると注意が必要でした。

  • 多くの場合、空き容量の○% でinodeが設定されています。

  • 利用率が高くなると、空き容量があってもinode不足で書き込みができない事象が発生します。この場合、df -iでinode数を確認し、設定変更を行うと解消できます。

ハードウェア／OSチューニング

• NIC (Network Interface Card)

  • 高いネットワークパフォーマンスを実現するため、サーバー用NICは必須です。バースト的なパケット処理能力はデスクトップ用NICとは大きく異なります。

  • LinuxやBSDでのドライバーサポートを考慮し、長年Intel製を使用していましたが、最近ではBroadcom製も含まれると思われます。

• メモリ
  サーバーソフトウェアを多数同時に動作させるには、CPU性能よりもメモリ容量が重要で、メモリ容量は確保するようにしていました。

• OSチューニング

  • 良く知られていますが、高性能な機材を用意しても、適切なチューニングを行わなければサーバーとしての性能は発揮されません。

  • es.netのHost Tuning を参考にすることが多く、実運用でも効果を感じていました。

サーバーソフトウェア

http/https、ftp、rsync、アクセス制限などで使用していた、KDDI総合研究所 公開FTPサーバー 上のソフトウェアを紹介します。基本的にはOSディストリビューション標準のソフトウェアを利用していました。しかし、セキュリティリスクを抑えるため、http/httpsやftpサーバーに用いるソフトウェアは必要最小限の機能に絞って工夫して運用していました。これにより、30年以上の運用期間中、セキュリティ面での問題は一度も発生しませんでした。

http/https: Apache
CDNに移行したApacheのミラー条件に、Apache httpdの利用が求められていた時期があり、最後まで使い続けました。ソフトウェアはコンパイルして使用しており、公開FTPサーバーでのファイル転送に特化し、機能を最小限にすることでセキュリティリスクを抑えるようにしていました。以下のコンパイルオプションで、CGIや認証などの一般的に使われる機能は無効化され、公開FTPサーバーに必要なDirectory ListingやAlias機能が有効化されていることが見ていただけると思います。

ftp: vsftpd
いくつかのFTPサーバーソフトを使ってきましたが、4代目以降はvsftpdを採用していました。SecureかつSimpleであることに加え、anonymous FTP onlyモードが利用できる点が大きな理由です。この設定により、ユーザ認証は無効となり、anonymous FTPによる公開エリアへのアクセスのみが可能になります。

もちろん、運用試験中だった6代目公開FTPサーバーも同様の設定でした。侵入騒ぎがあった際の証拠としたのも公開エリアへのアクセスで、anonymous FTPサーバーを知らない世代が多くなってきたように感じた出来事でした。

その他の工夫

• baddogとgoodboy
  KDDI総合研究所の公開FTPサーバーは、DoSや不正パケット送信などの攻撃を常時受けていました。OSやサーバーソフトの更新による対策に加え、2つのスクリプトをcronで定期的に実行することで追加の対策を行っていました。公開FTPサーバーは同時アクセス数に制限があるため、あるホストからの接続数が一定を超えると攻撃と判断できます。このために、スクリプト「baddog」で接続数を監視し、一定以上のIPに制限をかけ、「goodboy」で一定時間後に解除する運用をしていました。
  
  本来はアプリケーションファイアウォールで対応するのが理想ですが、機器の調達や保守には費用がかかります。予算があればディスク容量の拡張を優先したいという思惑もあり、サーバー内で実現可能なこの方法を採用していました。それなりに効果はあったように感じています。

• もちろん、一般的なセキュリティ対策を実施していました。

  • ファイアウォールの設定、必要最低限のポートのみの解放

  • ログの取得

  • sshポートのデフォルトからの変更、公開鍵認証のみ、rootアクセス不可

  • OSやパッケージの更新

文字ばかりの長文の記事を最後までお読みいただき、ありがとうございました。この記事が、サーバーやネットワークの運用に携わっている方に少しでもお役に立てばうれしいです。