最近、大規模企業を含め、サイバー攻撃や不正アクセスの被害が相次いで報じられています。インターネット上でサービスを提供する以上、事業規模にかかわらず、サーバー セキュリティを継続して確認することが欠かせません。
SilverArcsでも、自社が運用するAIサービス基盤について、「外部から攻撃を受けている形跡はあるか」「実際に侵入された可能性はないか」「侵入後の改ざんやバックドアが残されていないか」という観点から、2026年10月にサーバー侵害チェックを実施しました。
対象は、English Coach AI系サービスを運用するサーバーと、ミマベル等を運用するサーバーの2台のLinux VPSです。本記事では、具体的な構成や機密情報を伏せたうえで、小規模事業者や個人開発者にも参考になる確認の考え方を紹介します。これは専門的なデジタルフォレンジック調査の報告書や「安全宣言」ではなく、公開可能な範囲での運用記録です。
なぜサーバー侵害チェックを行ったのか
Webサーバーには、SSH、Web、WordPressなどを狙う自動スキャンやログイン試行が日常的に届きます。攻撃を完全にゼロにすることはできません。そこで重要になるのが、入口の防御だけでなく、万一の侵入成功や侵入後の改ざんを示す証拠がないかを複数の観点から確認することです。
今回の確認では、SSH セキュリティ、ファイアウォール、公開ポート、ソースコード、ファイル、プロセス、常駐設定、OSパッケージの整合性を横断的に調べました。
「攻撃されている」と「侵入された」は別
サーバーのログに多数の失敗記録や、存在しないユーザー名を使った試行が残っていると、不安を感じるかもしれません。しかし、攻撃ログが大量にあること自体は、侵入されたことを意味しません。
判断には、認証成功履歴、使用された公開鍵、稼働中のプロセス、待ち受けポート、ファイル改ざん、再起動後も動作する常駐設定、OS実行ファイルの整合性など、複数の証拠を組み合わせる必要があります。今回も多数の自動攻撃試行を確認しましたが、試行の存在と侵入の成功を分けて評価しました。
今回確認した主な項目
SSHログイン履歴と公開鍵
SSHへの大量のログイン試行、存在しないユーザー名を使った自動攻撃、ログイン成功履歴を確認しました。さらに、成功時に使われた公開鍵とサーバーに登録済みの鍵を照合し、未知の鍵によるログイン成功がないことを確認しました。
SSH設定については、現在パスワード認証を無効にし、公開鍵認証を使用していること、設定ファイルの変更状況、登録済み公開鍵を確認しました。過去には構築・移行の過程で一部パスワード認証を利用していた期間もありましたが、現在は無効化済みです。当時使用していたrootパスワードも現在とは異なり、現在の認証方式とは切り離されています。
ファイアウォールとfail2ban
UFWによるファイアウォール設定と外部公開範囲を確認し、Webサービス以外の内部サービスが直接外部に公開されていないかを点検しました。VPS セキュリティでは、必要な通信だけを許可し、外部から到達できる入口を最小限にすることが基本です。
また、SSHへの大量の自動攻撃に対して、fail2banが攻撃元を自動的に検知し、一時的に遮断していることも確認しました。攻撃元や件数の詳細は、安全上の理由から公開しません。
Gitによる本番コードの整合性
主要な本番サービスについて、本番サーバー上のソースコードが、管理しているリポジトリと整合しているかを確認しました。本番の状態、リモートリポジトリ、未反映の差分を比較し、意図しない改変がないかを点検しました。
Webシェル・不審ファイル
Webシェル、不審なPHPファイル、バックドアを疑うファイル名、難読化されたコード、一時領域に置かれた不審な実行ファイルなど、典型的なサーバー侵害の痕跡を検索しました。
単純な文字列検索では、正規のWordPressファイルやNode.jsの依存ライブラリが候補になる場合があります。そのため、検出結果を機械的に「不正」と判断せず、配置場所やファイルの役割を確認し、誤検知を切り分けました。
SUID / SGID
Linuxでは、SUIDやSGIDが設定された実行ファイルが権限昇格に悪用されることがあります。サーバー内を確認した結果、OS標準パッケージ由来のもの以外に、不審なSUID rootファイルは確認されませんでした。
systemdと永続化
攻撃者が再起動後もマルウェアを動かし続けるため、systemdのサービス登録などを悪用することがあります。自社で設定したサービス、プロセス管理ツール、既知の定期処理と照合し、それ以外の不審なsystemdサービスがないかを確認しました。
あわせて、Linuxマルウェアやrootkitで使われることがあるLD_PRELOAD、LD_LIBRARY_PATH、rc.local、予約実行ジョブなども確認し、今回の調査では不審な永続化設定は確認されませんでした。
OSパッケージの整合性
OS標準パッケージの整合性確認も行いました。運用上の設定変更を除き、OS実行バイナリが改ざんされたことを示す明確な兆候は確認されませんでした。
確認結果
2026年10月時点の確認範囲では、不正侵入・改ざんを示す痕跡は確認されませんでした。
具体的には、次の項目は確認されませんでした。
- 不審なSSHログイン成功
- 未知のSSH公開鍵
- Webシェル
- 不審なsystemd常駐
- 不審なSUID rootファイル
- LD_PRELOADを使った永続化
- OS実行ファイルの明確な改ざん
- 本番Git管理コードの意図しない差分
ただし、これは2026年10月時点に実施した確認の範囲に基づく結果です。あらゆる侵害可能性を将来にわたって否定するものではなく、継続的な監視と再確認が必要です。
今回分かったこと
小規模事業者 セキュリティの実務では、高価な仕組みを一度導入して終わりにするのではなく、複数の証拠を地道に突き合わせることが重要です。入口のSSHログだけで判断せず、鍵、ネットワーク、コード、ファイル、常駐設定、OSの整合性まで確認することで、見落としを減らせます。
また、通常のWordPressファイルや依存ライブラリを不審ファイルと誤認しないためには、検出結果を人が精査する工程も欠かせません。Linux セキュリティでは、ツールの結果そのものより、なぜその結果になったかを確認する姿勢が大切だと改めて感じました。
今後も継続して改善する
今回の結果に安心して終わるのではなく、次の改善を継続します。
- SSH認証方式と管理者権限運用の継続的な見直し
- 外部公開ポートの最小化
- SSHログイン成功時の監視
- 未知のSSH鍵や新規接続元の検知
- Gitを使った本番コード変更管理
- OS・ミドルウェア・アプリケーションの定期的なアップデート
- サーバー監視、バックアップ、定期的な侵害確認
SilverArcsでは、English Coach AIやミマベルなど、AIを利用したサービスを運営しています。AI機能そのものだけでなく、サービスを安全に運用し続けるための基盤管理もサービス品質の一部だと考えています。
今後も機能開発と並行して、サーバー、ネットワーク、認証、バックアップ、監視などの改善を継続していきます。