はじめに
先日、IBM Bobを活用してUbuntu24.04のMCPサーバーを開発した記事を投稿しました。
この時点では、リソース使用率に基づくインサイトしか得ることはできませんでしたが、本日セキュリティー診断とネットワーク診断を行う為のツールをIBM Bobで追加で開発し、現行のUbunutu MCPサーバーへの機能拡張を行いました。
本記事では追加した両ツールの概要と使用感をご紹介します。
IBM Bobでの追加開発内容
前回同様に、Windows11上のBob IDEからリモートエクスプローラー経由でWSL2(Ubuntu24.04)に接続後、下記のようなプロンプトを実行しました。
先日はUbuntu LinuxのMCPサーバーを開発いただきありがとうございました。こちらのMCPサーバーの機能拡張をしたいのですが、以下のような内容の機能を追加してもらうことは可能でしょうか？・セキュリティーに関するパラメータなどを確認し、何かしらのインサイトを提供してくれる機能(セキュリティー順守確認レポートの出力、問題時の対応案の提案など)・ネットワークに関するパラメータなどを確認し、何かしらのインサイトを提供してくれる機能(当Ubuntu Linuxが接続しているネットワーク状況表示、問題時の対応案の提案など)
前回の開発から1週間ほど経過していたので、Bob君は既存のMCPサーバーのコードを確認した後、下記の新規2つのツールを開発、index.tsファイルに追加後、ビルド処理を実施してくれました。
- get_security_audit ： セキュリティー診断・コンプライアンスレポート作成
- get_network_insights ： ネットワーク詳細診断
各々のツールで収集可能な情報については、下記GitHubリポジトリのREADMEをご参照ください。
IBM Bobでの稼働確認
2つの新規ツールの実装、Bob君側での稼働確認が終わった後、今回は下記のようなプロンプトを実行してみました。
セキュリティー診断ツールの使用例
現行システムのセキュリティー診断レポートを作成してください。
Bob君は一通り必要な情報を今回の新しいツールを用いて抽出し、最終的に下記のようなレポートを作成してくれました。
# セキュリティ診断レポート
**対象OS:** Ubuntu 24.04.4 LTS (WSL2)
**CPU:** 13th Gen Intel Core i5-1335U
**診断日時:** 2025年
---
## 総合スコア: 52 / 100 — ⚠ 問題あり
| 重大度 | 件数 |
|--------|------|
| 🔴 重大 (Critical) | 0 件 |
| 🔴 高 (High) | 2 件 |
| 🟡 中 (Medium) | 2 件 |
| 🔵 低 (Low) | 2 件 |
---
## システム情報
| 項目 | 内容 |
|------|------|
| OS | Ubuntu 24.04.4 LTS |
| 環境 | WSL2 (Windows Subsystem for Linux 2) |
| CPU | 13th Gen Intel Core i5-1335U |
| メモリ | 7,779 MB 中 1,300 MB 使用 (17%) |
| ディスク (/) | 1007 GB 中 3.2 GB 使用 (1%) |
| 稼働時間 | 約 5 分 |
| UID 0 アカウント | root のみ（正常） |
| 空パスワードアカウント | なし（正常） |
| 自動セキュリティ更新 | 有効（正常） |
---
## ✔ 問題なし（良好な設定）
- **空パスワードアカウントなし** — 全アカウントにパスワードが設定されています。
- **UID 0 は root のみ** — 不正な特権アカウントは存在しません。
- **自動セキュリティ更新が有効** — `Unattended-Upgrade "1"` が設定済みです。
- **公開鍵認証が有効** — `PubkeyAuthentication yes` — 鍵認証が利用可能です。
---
## ⚠ 検出された問題
### 🔴 高 (High)
#### 1. ファイアウォール無効
**詳細:** UFW がインストールされていないか、無効化されています。外部からのすべての受信接続がフィルタリングされていません。
**対処方法:**
sudo ufw enable && sudo ufw default deny incoming && sudo ufw allow ssh
---
#### 2. 不審な SUID/SGID ファイル検出
**詳細:** 既知リストに含まれない SUID/SGID ファイルが 9 件検出されました。各ファイルが正規のものか確認が必要です。
| パス | 判定 |
|------|------|
| `/usr/bin/chage` | 要確認 |
| `/usr/bin/crontab` | 要確認 |
| `/usr/bin/expiry` | 要確認 |
| `/usr/bin/ssh-agent` | 要確認 |
| `/usr/lib/landscape/apt-update` | 要確認 |
| `/usr/lib/polkit-1/polkit-agent-helper-1` | 要確認 |
| `/usr/lib/x86_64-linux-gnu/utempter/utempter` | 要確認 |
| `/usr/sbin/pam_extrausers_chkpwd` | 要確認 |
| `/usr/sbin/unix_chkpwd` | 要確認 |
**対処方法:**
# 各ファイルの帰属をパッケージで確認
dpkg -S <ファイルパス>
# 不要であれば権限を削除
chmod u-s <ファイルパス>
chmod g-s <ファイルパス>
---
### 🟡 中 (Medium)
#### 3. ICMP リダイレクト受け入れ有効
**詳細:** `net.ipv4.conf.all.accept_redirects = 1` — 悪意あるルータがルーティングテーブルを改ざんできる状態です。
**対処方法:**
# 即時適用
sudo sysctl -w net.ipv4.conf.all.accept_redirects=0
# 永続化 (/etc/sysctl.conf に追記後)
sudo sysctl -p
---
#### 4. SSH パスワード認証が有効
**詳細:** `PasswordAuthentication yes` — ブルートフォース攻撃でパスワードを総当たりされるリスクがあります。
**対処方法:**
# /etc/ssh/sshd_config を編集
PasswordAuthentication no
# 公開鍵ログインを事前に確認した上で実行
sudo systemctl restart sshd
---
### 🔵 低 (Low)
#### 5. SSH デフォルトポート (22) 使用
**詳細:** 標準ポートを使用しているため、自動化されたスキャンツールによる攻撃ターゲットになりやすい状態です。
**対処方法:**
# /etc/ssh/sshd_config を編集（例: 2222 に変更）
Port 2222
ファイアウォールの許可設定も合わせて更新が必要です。
---
#### 6. SSH 認証試行回数が多い (MaxAuthTries = 6)
**詳細:** デフォルト値のままのため、ブルートフォース攻撃時に 6 回試行できます。
**対処方法:**
# /etc/ssh/sshd_config を編集
MaxAuthTries 3
sudo systemctl restart sshd
---
## リスニングポート一覧
| プロトコル | アドレス:ポート | 用途 |
|-----------|----------------|------|
| TCP | 0.0.0.0:22 / [::]:22 | SSH |
| TCP | 127.0.0.1:40169 | node プロセス (PID 1050) ※ローカルのみ |
| TCP/UDP | 127.0.0.54:53, 127.0.0.53:53, 10.255.255.254:53 | DNS (systemd-resolved) |
| UDP | 127.0.0.1:323, [::1]:323 | chrony (NTP) |
---
## 優先対応アクション（推奨順）
| # | 対応内容 | 優先度 |
|---|----------|--------|
| 1 | UFW ファイアウォールを有効化し、デフォルト拒否ルールを適用する | 🔴 高 |
| 2 | SSH のパスワード認証を無効化し、公開鍵認証のみに制限する | 🔴 高 |
| 3 | SUID/SGID ファイルを `dpkg -S` で確認し、不正なものを除去する | 🔴 高 |
| 4 | ICMP リダイレクト受け入れを無効化し `/etc/sysctl.conf` で永続化する | 🟡 中 |
| 5 | SSH の `MaxAuthTries` を 3 に設定してブルートフォースを抑制する | 🔵 低 |
| 6 | SSH ポートをデフォルト 22 から変更することを検討する | 🔵 低 |
このWSL2のUbuntu環境は作成して日が浅く、Ubuntuの提供しているファイアーウォール機能である「ufw」コマンドもまだインストールしていない状態だったので、ぼろぼろと粗が見つかりました。。対応が必要ですね。
ネットワーク診断ツールの使用例
今回はシンプルに下記のようなプロンプトを入力してみました。
現行のシステムにおいて、外部と正しくネットワーク通信できているかを確認してください。
Bob君は一通り新規ツールを利用して情報抽出し、下記のような診断をしてくれました。
診断完了です。重要な結果をまとめます。
---
### ネットワーク疎通確認結果
| チェック項目 | 結果 |
|---|---|
| **外部インターネット接続** (8.8.8.8) | ✅ **正常** — RTT 約 4.6 ms、パケットロス 0% |
| **デフォルトゲートウェイ** (172.17.32.1) | ⚠️ **ICMP 応答なし** (100% packet loss) |
| **eth0 インターフェース** | ✅ UP — IP: 172.17.47.69/20 |
| **DNS サーバー** (10.255.255.254) | ✅ WSL2 内部 DNS が設定済み |
| **ARP テーブル** | ✅ ゲートウェイの MAC は REACHABLE (物理接続あり) |
---
### 判断
**外部との通信は正常に機能しています。**
「ゲートウェイへの ping が通らない」という High 検出が出ていますが、これは **WSL2 特有の既知の動作** です。
- ARP テーブルにゲートウェイの MAC アドレス (`00:15:5d:e9:51:4c`) が `REACHABLE` として登録されており、**L2 (データリンク層) での接続は確立しています**
- 実際に `8.8.8.8` (Google DNS) へのパケットが往復できているため、ゲートウェイ越しのルーティングも正常に機能しています
- WSL2 のゲートウェイ (Hyper-V 仮想スイッチ) は ICMP Echo に応答しないよう設定されているケースが一般的で、これが ping 100% loss の原因です
**結論: 外部ネットワークとの通信に問題はありません。**
WSL2固有の特性も踏まえた診断もしてくれてよかったです。
AWS Kiroでの稼働確認
公開先のGithubリポジトリをクローンし、手順に従いパッケージのビルドを行います。mcp.jsonの設定内容は変わらないので、ビルドが終了してMCPサーバーがリフレッシュされれば使用可能です。
セキュリティー診断ツールの使用例
今回は下記のようなプロンプトを実行しました。
現行のシステムにおけるセキュリティー設定状況を確認し、セキュリティー診断レポートを作成してください。問題があるようであれば、対応案を提案してください。
その後、Kiroは今回既存のubuntu-insights MCPサーバーに追加した「get_security_audit」ツールを使用して必要な情報を抽出します。
最終的に下記のマークダウンファイルに見られるような診断結果をレポートしてくれました。
security-audit-report.md
# セキュリティ診断レポート
**診断日:** 2026年7月8日
**対象システム:** Linux (Ubuntu)
---
## 総合評価
| 項目 | 結果 |
|------|------|
| スコア | **60 / 100** |
| 評価 | **要改善** |
| 検出件数 | 6件（High: 1, Medium: 3, Low: 2） |
---
## 検出された問題と対応案
### 1. [High] ファイアウォールが無効
**状況:** UFW（Uncomplicated Firewall）がインストールされていない、または無効になっています。外部からの不要な接続をブロックする手段がありません。
**対応案:**
sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw enable
---
### 2. [Medium] IPフォワーディングが有効
**状況:** `net.ipv4.ip_forward = 1` が設定されています。このシステムがルーターやVPNサーバーとして使われていない場合、不要な設定であり、攻撃経路を広げるリスクがあります。
**対応案:**
# 即時無効化
sudo sysctl -w net.ipv4.ip_forward=0
# 永続化（/etc/sysctl.conf に以下を追加/変更）
net.ipv4.ip_forward = 0
---
### 3. [Medium] SSH パスワード認証が有効
**状況:** `PasswordAuthentication` が `yes`（またはデフォルトの `yes`）のままです。ブルートフォース攻撃のターゲットになりやすい状態です。
**対応案:**
# /etc/ssh/sshd_config を編集
PasswordAuthentication no
# SSHサービスを再起動
sudo systemctl restart sshd
> 注意: 公開鍵認証が正しく設定されていることを確認してから実施してください。
---
### 4. [Medium] ワールドライタブルなファイルが存在
**状況:** `/home/testuser/test/alb_lambda_rds/` 配下に、誰でも書き込み可能なファイルが複数存在しています（Terraform設定ファイルなど）。
**対応案:**
# 対象ディレクトリ内のワールドライタブル権限を一括削除
find /home/testuser/test/alb_lambda_rds/ -type f -perm -o+w -exec chmod o-w {} \;
---
### 5. [Low] SSHがデフォルトポート（22）を使用
**状況:** SSHが標準の22番ポートで待ち受けています。自動スキャンによるブルートフォース攻撃の対象になりやすい状態です。
**対応案:**
# /etc/ssh/sshd_config を編集
Port 2222 # 任意の非標準ポート番号
sudo systemctl restart sshd
> ファイアウォールルールも忘れず変更してください。
---
### 6. [Low] SSH認証試行回数が多い（MaxAuthTries = 6）
**状況:** 認証失敗を6回まで許容する設定になっており、ブルートフォースに対する耐性が低めです。
**対応案:**
# /etc/ssh/sshd_config を編集
MaxAuthTries 3
sudo systemctl restart sshd
---
## その他の確認事項（良好）
| 項目 | 状態 |
|------|------|
| root以外のUID 0アカウント | なし（正常） |
| パスワード空のアカウント | なし（正常） |
| 不審なSUID/SGIDファイル | なし（正常） |
| 自動セキュリティ更新 | 有効（正常） |
| 最近のログイン失敗 | 2回（少数、問題なし） |
---
## リスニングポート一覧
| プロトコル | アドレス | ポート | プロセス |
|-----------|---------|--------|---------|
| TCP | 0.0.0.0 | 22 | sshd |
| TCP | [::] | 22 | sshd |
| TCP | * | 21 | ftpd |
| TCP | 127.0.0.1 | 631 | cupsd |
| TCP | [::1] | 631 | cupsd |
| TCP | 127.0.0.1 | 40677 | node |
| TCP | 127.0.0.1 | 39005 | node |
| TCP | 127.0.0.54 | 53 | systemd-resolved |
| UDP | 0.0.0.0 | 5353 | mDNS |
| UDP | 127.0.0.54 | 53 | systemd-resolved |
---
## 優先対応順序
1. **ファイアウォール有効化**（最優先 — 外部攻撃防止の最も基本的な防壁）
2. **SSHパスワード認証の無効化**（公開鍵認証への移行）
3. **IPフォワーディングの無効化**（不要であれば）
4. **ワールドライタブルファイルの権限修正**
5. SSH MaxAuthTries の制限、ポート変更（任意）
---
## カーネルパラメータ詳細
| パラメータ | 値 | 評価 |
|-----------|---|------|
| net.ipv4.ip_forward | 1 | 要確認（不要なら無効化） |
| net.ipv4.conf.all.accept_redirects | 0 | 良好 |
| net.ipv4.conf.all.send_redirects | 1 | 要確認 |
| net.ipv4.conf.all.rp_filter | 2 | 良好（loose mode） |
| net.ipv6.conf.all.forwarding | 0 | 良好 |
個人の検証環境で自由に使っているせいか、色々とシステム上の粗が見つかりました。。。
ネットワーク診断ツールの使用例
続けて下記のようなプロンプトを実行してみました。
次は、現行システムのネットワーク設定状況を確認し、ネットワーク診断レポートを作成してください。問題があるようであれば、対応案のご提案をお願いします。
その後、Kiroは今回既存のubuntu-insights MCPサーバーに追加した「get_network_insights」ツールを使用して必要な情報を抽出します。
最終的に下記のマークダウンファイルに見られるような診断結果をレポートしてくれました。
network-diagnostic-report.md
# ネットワーク診断レポート
**診断日:** 2026年7月8日
**対象システム:** Linux (Ubuntu)
---
## 総合評価
| 項目 | 結果 |
|------|------|
| 検出件数 | 3件（High: 1, Medium: 1, Info: 1） |
| 外部接続性 | **正常（OK）** |
| ゲートウェイ接続性 | **正常（OK）** |
---
## 接続性テスト結果
| テスト | 対象 | 結果 | 応答時間 |
|--------|------|------|---------|
| ゲートウェイ Ping | 192.168.137.2 | 成功（0% パケットロス） | avg 0.315ms |
| 外部 Ping | 8.8.8.8 | 成功（0% パケットロス） | avg 10.407ms |
---
## 検出された問題と対応案
### 1. [High] 危険なポートが公開されている: 21/FTP（平文通信）
**状況:** `*:21` で FTP サービスが全インターフェースに対して待ち受けています。FTP は通信内容（認証情報含む）が平文で送信されるため、盗聴リスクがあります。
**対応案:**
# FTPサービスの停止と無効化
sudo systemctl stop vsftpd # または proftpd 等
sudo systemctl disable vsftpd
# 代替手段: SFTP（SSH経由のファイル転送）を使用
# SSH が既に稼働しているため、追加設定なしでSFTPが利用可能です
sftp user@hostname
> FTP が業務上必要な場合は、FTPS（FTP over TLS）への移行を検討してください。
---
### 2. [Medium] ダウン状態のネットワークインターフェース検出
**状況:** `docker0` インターフェースが DOWN 状態です（NO-CARRIER）。Docker コンテナが稼働していない場合に発生する正常な状態ですが、Docker を使用予定がなければ不要なインターフェースです。
**対応案:**
# Docker を使用しない場合: Docker サービスの停止
sudo systemctl stop docker
sudo systemctl disable docker
# Docker を使用する場合: コンテナ起動時に自動的に UP になるため対応不要
---
### 3. [Info] ループバック DNS 使用中
**状況:** DNS サーバーが `127.0.0.53`（systemd-resolved ローカルリゾルバー）に設定されています。これは Ubuntu の標準構成であり、正常です。
**確認コマンド:**
resolvectl status
---
## ネットワークインターフェース一覧
| インターフェース | 状態 | IPv4 アドレス | IPv6 アドレス | MTU |
|----------------|------|--------------|--------------|-----|
| lo | UP | 127.0.0.1/8 | ::1/128 | 65536 |
| ens33 | UP | 192.168.137.131/24 | fe80::7f34:bb22:1088:8b1b/64 | 1500 |
| ens34 | UP | 192.168.65.131/24 | fe80::20c:29ff:fe38:f97/64 | 1500 |
| docker0 | DOWN | 172.17.0.1/16 | - | 1500 |
---
## トラフィック統計
| インターフェース | 受信バイト | 送信バイト | 受信エラー | 送信エラー | ドロップ(RX) | ドロップ(TX) |
|----------------|-----------|-----------|-----------|-----------|------------|------------|
| lo | 4,458,184 | 4,458,184 | 0 | 0 | 0 | 0 |
| ens33 | 256,521,878 | 6,804,242 | 0 | 0 | 0 | 0 |
| ens34 | 16,644 | 16,062 | 0 | 0 | 0 | 0 |
| docker0 | 0 | 0 | 0 | 0 | 0 | 30 |
> 全インターフェースでエラー・ドロップなし（docker0 の TX ドロップ 30 はコンテナ未稼働時の正常動作）。
---
## ルーティングテーブル
| 宛先 | ゲートウェイ | インターフェース | プロトコル | メトリック |
|------|------------|----------------|----------|----------|
| default (0.0.0.0/0) | 192.168.137.2 | ens33 | DHCP | 100 |
| 172.17.0.0/16 | - (直接接続) | docker0 | kernel | - (linkdown) |
| 192.168.65.0/24 | - (直接接続) | ens34 | kernel | 101 |
| 192.168.137.0/24 | - (直接接続) | ens33 | kernel | 100 |
---
## リスニングポート一覧
### TCP
| アドレス | ポート | プロセス | 公開範囲 |
|---------|--------|---------|---------|
| 0.0.0.0 | 22 | sshd | 全ネットワーク |
| [::] | 22 | sshd | 全ネットワーク |
| * | 21 | ftpd | 全ネットワーク |
| 127.0.0.1 | 631 | cupsd | ローカルのみ |
| [::1] | 631 | cupsd | ローカルのみ |
| 127.0.0.1 | 40677 | node (pid=4898) | ローカルのみ |
| 127.0.0.1 | 39005 | node (pid=4972) | ローカルのみ |
| 127.0.0.1 | 45393 | - | ローカルのみ |
| 127.0.0.54 | 53 | systemd-resolved | ローカルのみ |
| 127.0.0.53 | 53 | systemd-resolved | ローカルのみ |
### UDP
| アドレス | ポート | 用途 |
|---------|--------|------|
| 0.0.0.0 | 5353 | mDNS |
| [::] | 5353 | mDNS |
| 0.0.0.0 | 48684 | 一時ポート |
| [::] | 54166 | 一時ポート |
| 127.0.0.54 | 53 | systemd-resolved |
| 127.0.0.53 | 53 | systemd-resolved |
---
## 接続概要
| 項目 | 値 |
|------|---|
| TCP 合計 | 23 |
| TCP 確立済み (ESTABLISHED) | 12 |
| TCP クローズ済み | 1 |
| TCP タイムウェイト | 1 |
| UDP 合計 | 8 |
| 全プロトコル合計 | 782 |
---
## ARP テーブル
| IP アドレス | インターフェース | MAC アドレス | 状態 |
|------------|----------------|-------------|------|
| 192.168.137.2 | ens33 | 00:50:56:e8:60:b1 | REACHABLE |
| 192.168.137.1 | ens33 | 00:50:56:c0:00:08 | REACHABLE |
| 192.168.137.254 | ens33 | 00:50:56:e4:3e:01 | STALE |
| 192.168.65.1 | ens34 | 00:50:56:c0:00:01 | STALE |
| 192.168.65.254 | ens34 | 00:50:56:ea:33:cf | STALE |
---
## DNS 設定
| 項目 | 値 |
|------|---|
| リゾルバー | systemd-resolved（ローカルスタブ） |
| ネームサーバー | 127.0.0.53 |
| オプション | edns0, trust-ad |
| 検索ドメイン | localdomain |
---
## 優先対応順序
1. **FTPサービスの停止/SFTP移行**（最優先 — 平文通信による認証情報漏洩リスク）
2. **Docker不要時のサービス停止**（リソース節約・攻撃面削減）
3. systemd-resolved の稼働確認（情報レベル、通常対応不要）
---
## NetworkManager 状態
| 項目 | 状態 |
|------|------|
| 全体状態 | connected |
| 接続性 | full |
| WiFi HW | missing |
| WiFi | enabled |
| WWAN HW | missing |
| WWAN | enabled |
FTPは平文なので、確かにSFTP(SSH-FTP)に移行したほうが良いですね。。。
Claude Codeでの稼働確認
今月から個人検証用にClaude CodeのProプランに課金することにしたので、Claude Codeでの稼働確認もしてみることにしました。Claude Codeの場合は、AWS Kiroのmcp.jsonファイルの中身をそっくりそのまま、Claude Code用のワークスペース・フォルダ内に「.mcp.json」という名前のファイルにコピーした後、Claude Codeを起動すればOKです。
セキュリティー診断ツールの使用例
AWS Kiroと同じプロンプトを実行します。
現行のシステムにおけるセキュリティー設定状況を確認し、セキュリティ診断レポートを作成してください。問題があるようであれば、対応案を提案してください。
たまたま、VS Code上で「.mcp.json」ファイルを開いていたからか、Claude Codeの場合はセキュリティー診断ツール(get_security_audit)とネットワーク診断ツール(get_network_insights)、他に既存のシステム概要抽出ツール(get_system_overview)、稼働サービス抽出ツール(get_running_service)を合わせ技で情報抽出する動きが見られました。
最終的に下記のマークダウンファイルに見られるような診断レポートが作成されました。
security-report.md
# セキュリティ診断レポート
対象: Ubuntu 24.04.4 LTS
稼働時間: 1時間5分
診断日: 2026-07-08
診断ツール: ubuntu-insights MCP（`get_security_audit` / `get_network_insights` / `get_system_overview` / `get_running_services`）
## 総合サマリー
- **総合スコア: 60 / 100（要改善）** ※ホストセキュリティ監査（`get_security_audit`）による評価
- 指摘件数: **High 2 / Medium 3 / Low 2**（合計 7件）
| 深刻度 | 件数 | 内容 |
|---|---|---|
| High | 2 | ファイアウォール無効、FTP（平文）公開 |
| Medium | 3 | IPフォワード有効、SSHパスワード認証有効、ワールドライタブルファイル |
| Low | 2 | SSHデフォルトポート、MaxAuthTries既定値 |
---
## 1. ネットワーク境界（High）
### 1-1. ファイアウォール（UFW）が無効
- **深刻度**: High
- **詳細**: UFW が有効化されておらず、`ufw` コマンドも見つからない（`ufw: not found`）。ホストへの受信トラフィックが未フィルタの状態。
- **対応**:
sudo apt install ufw
sudo ufw default deny incoming
sudo ufw allow ssh
sudo ufw enable
### 1-2. FTP（平文通信・21番ポート）が全インターフェースで待受中
- **深刻度**: High
- **詳細**: `vsftpd.service` が稼働し `*:21` で待受。FTP は認証情報・データとも平文送信のため、盗聴やクレデンシャル窃取のリスクがある。
- **対応**:
# 不要であれば停止
sudo systemctl disable --now vsftpd
# 必要な場合は SFTP（SSH経由）へ移行するか、
# vsftpd を TLS 必須（ssl_enable=YES, force_local_data_ssl=YES）に設定
---
## 2. SSH設定（Medium / Low）
### 2-1. パスワード認証が有効（Medium）
- **詳細**: `PasswordAuthentication` が未設定（既定で yes）。総当たり攻撃で突破される可能性。
- **対応**:
# /etc/ssh/sshd_config.d/ 配下に設定を追加
PasswordAuthentication no
sudo systemctl restart ssh
### 2-2. MaxAuthTries が既定値（6）のまま（Low）
- **詳細**: 1接続あたり6回まで認証試行が可能で、総当たり耐性がやや低め。
- **対応**: `MaxAuthTries 3` を追加して `sshd` を再起動。
### 2-3. SSHがデフォルトポート22で待受（Low）
- **詳細**: 必須ではないが、既定ポートは自動スキャン・ブルートフォースの標的になりやすい。
- **対応**: 鍵認証化（上記）を優先。運用上支障なければ `Port` 変更も検討。
---
## 3. カーネル / ファイルシステム（Medium）
### 3-1. IPフォワーディングが有効
- **詳細**: `net.ipv4.ip_forward = 1`。本ホストがルーター／VPNゲートウェイでない場合、意図しないパケット転送を許す設定。
- **対応**:
sudo sysctl -w net.ipv4.ip_forward=0
# /etc/sysctl.conf にも net.ipv4.ip_forward=0 を記載して永続化
### 3-2. ワールドライタブル（誰でも書込可）なファイルを検出
- **詳細**: 最大30件検出。抜粋:
/home/testuser/test/alb_lambda_rds/main.tf
/home/testuser/test/alb_lambda_rds/versions.tf
/home/testuser/test/alb_lambda_rds/modules/RDS-Setup/variables.tf
/home/testuser/test/alb_lambda_rds/modules/RDS-Setup/main.tf
/home/testuser/test/alb_lambda_rds/modules/EC2-Setup/variables.tf
...
- **対応**:
# 該当ファイルを確認のうえ書込権限を剥奪
chmod o-w /home/testuser/test/alb_lambda_rds/main.tf
---
## 4. 攻撃対象領域（参考）
個別の指摘ではないが、以下のサービスが同時に稼働しており外部到達可能な経路が多い状態。用途を再確認すること。
| サービス | 用途 | 備考 |
|---|---|---|
| vsftpd | FTP (21) | 上記 High 指摘の対象 |
| ssh | SSH (22) | 鍵認証化を推奨 |
| gnome-remote-desktop | リモートデスクトップ | 利用中でなければ停止を検討 |
| openvpn | VPN | service は active（exited）— 用途を確認 |
| docker / containerd | コンテナ実行基盤 | 公開ポートの棚卸しを推奨 |
---
## 5. 問題なし・良好な設定
- UID 0 は `root` のみ／空パスワードアカウントなし
- 疑わしい SUID・SGID ファイルなし
- `APT::Periodic::Unattended-Upgrade` 有効（自動更新設定済み）
- `KbdInteractiveAuthentication no`
---
## 6. その他の所見（セキュリティ外）
### ルートパーティションの使用率が94%（38GB中34GB使用）
- セキュリティ項目ではないが、空き容量逼迫はログ欠落や更新失敗の原因になる。不要ファイルの整理を推奨。
---
## 対応の優先順位
### 今すぐ（High）
1. UFW を導入・有効化し、既定で受信拒否＋SSHのみ許可する。
2. FTP（vsftpd, 21番ポート）を停止するか、TLS必須化・SFTPへの移行を行う。
### 近日中（Medium）
1. SSH を公開鍵認証のみに切り替え、パスワード認証を無効化する。
2. 不要な IP フォワーディングを無効化する（ルーター/VPN用途でない場合）。
3. 検出されたワールドライタブルファイルの権限を見直す。
### 計画的に（Low）
1. `MaxAuthTries` を 3 程度に引き下げる。
2. 運用に支障がなければ SSH の待受ポートを変更する。
3. gnome-remote-desktop / openvpn など未使用サービスの棚卸しと停止。
---
*本レポートは ubuntu-insights MCP による自動収集結果に基づく所見です。本番適用前に各コマンドの影響範囲を確認してください。*
いくつかのツールを合わせ技で利用されたからか、結構広範囲に診断してくれているようです。
ネットワーク診断ツールの使用例
一応、こちらも比較用にAWS Kiroと同じプロンプトを実行します。
ネットワーク診断レポートについても作成お願いします。
今回はネットワーク診断用のツール(get_network_insights)と既存のネットワーク情報抽出ツール(get_network_info)の2つを使用して、情報抽出が行われました。
最終的に下記のマークダウンファイルに見られるような診断レポートが作成されました。
network-report.md
# ネットワーク診断レポート
対象: Ubuntu 24.04.4 LTS
既定ゲートウェイ: `192.168.137.2`（`ens33`）
診断日: 2026-07-08
診断ツール: ubuntu-insights MCP（`get_network_insights` / `get_network_info`）
## 総合サマリー
| 項目 | 結果 |
|---|---|
| ゲートウェイ疎通 | OK（RTT avg 0.16ms, 192.168.137.2） |
| 外部疎通 | OK（RTT avg 10.8ms, 8.8.8.8, パケットロス 0%） |
| 指摘件数 | High 1 / Medium 1 / Info 1 |
---
## 1. インターフェース概要
| IF | 状態 | アドレス | 備考 |
|---|---|---|---|
| lo | UP | 127.0.0.1/8 | ループバック |
| ens33 | UP | 192.168.137.131/24 | 既定ルート（DHCP）。通信量が最大（受信 561MB） |
| ens34 | UP | 192.168.65.131/24 | サブネット別経路（metric 101）。通信量は少量 |
| docker0 | **DOWN** | 172.17.0.1/16 | NO-CARRIER。docker.service は稼働中だがブリッジ未接続 |
### docker0 ブリッジが DOWN 状態（Medium）
- **詳細**: Docker はサービスとして稼働しているが、ブリッジインターフェースがリンクダウンしており、コンテナ間通信・外部公開が機能しない可能性がある。意図した状態か確認が必要。
- **対応**:
sudo systemctl status docker
sudo ip link set docker0 up # 意図せず落ちている場合
---
## 2. 経路・DNS
| 宛先 | デバイス | Metric | 備考 |
|---|---|---|---|
| default | ens33 | 100 | via 192.168.137.2（DHCP） |
| 192.168.65.0/24 | ens34 | 101 | 直結経路 |
| 172.17.0.0/16 | docker0 | — | linkdown のため実質不通 |
**DNS（Info）**: `127.0.0.53`（systemd-resolved の stub resolver）経由。正常な構成。上流DNSは `resolvectl status` で確認可能。
---
## 3. 公開ポート（Listening）
| Proto | アドレス | 公開範囲 | 備考 |
|---|---|---|---|
| tcp | `*:21` | **全IF公開** | vsftpd（平文FTP）— 下記 High 指摘 |
| tcp | `0.0.0.0:22` / `[::]:22` | 全IF公開 | SSH。想定通りであれば問題なし |
| tcp | `127.0.0.1:631` / `[::1]:631` | ローカルのみ | CUPS印刷 |
| tcp | `127.0.0.1:46791` / `:35313` / `:45393` | ローカルのみ | エディタ/開発ツール（code-*） |
| udp | `0.0.0.0:5353` / `[::]:5353` | 全IF公開 | mDNS（Avahi）— LAN内探索用途、通常影響小 |
| udp/tcp | `127.0.0.54:53`, `127.0.0.53%lo:53` | ローカルのみ | systemd-resolved |
### 危険なポートが公開されている: 21/FTP（平文通信）（High）
- **詳細**: `*:21` で FTP が全インターフェースから到達可能。認証情報を含め平文送信のため、同一LAN上の第三者に盗聴されるリスクがある。
- **対応**:
sudo systemctl disable --now vsftpd
# 必要な場合は SFTP へ移行するか、vsftpd を TLS 必須構成に変更
---
## 4. アクティブな接続
ローカル発信元はすべて `192.168.137.131`（ens33）。
| リモート | プロセス | 状態 | 備考 |
|---|---|---|---|
| 192.168.137.1:50596 / :52095 | sshd (22) | ESTAB | 管理接続元。VMwareホスト側と推定 |
| 160.79.104.10:443 ×3 | claude | ESTAB | Claude Code / Anthropic API |
| 35.190.46.17:443 | claude | ESTAB | Claude Code 関連トラフィック |
| 52.195.201.233:443 | (aws-ssm/discovery) | ESTAB | AWS SSM Agent / Discovery Daemon 想定 |
| 52.195.202.255:443 | (aws-ssm/discovery) | ESTAB | 同上 |
| 3.173.254.75:443 | python (pid 13166) | **CLOSE-WAIT** | Recv-Q 25 — 未読データ残存、ソケット未クローズの疑い |
### pythonプロセスの接続が CLOSE-WAIT で滞留（Low）
- **詳細**: リモート（3.173.254.75:443）側はクローズ済みだが、ローカルの python プロセスがソケットを閉じておらず、受信キューに25バイトが残ったまま。恒常的に増え続ける場合はファイルディスクリプタ枯渇につながる。
- **確認**:
sudo ss -p state close-wait
# 該当PIDのアプリケーションでソケットクローズ処理を確認
---
## 5. 帯域・トラフィック健全性
| IF | RX | TX | エラー/ドロップ |
|---|---|---|---|
| lo | 14.9 MB | 14.9 MB | なし |
| ens33 | 561.8 MB | 20.8 MB | なし |
| ens34 | 28.5 KB | 23.6 KB | なし |
| docker0 | 0 B | 0 B | TXドロップ 32件（リンクダウンのため想定内） |
**良好な点**: ens33 / ens34 とも rxErrors・rxDropped・txErrors ともに 0。回線品質・NIC・ドライバ起因の問題は見られない。
---
## 対応の優先順位
### 今すぐ（High）
1. vsftpd（21番ポート、平文FTP）を停止するか TLS 必須構成へ変更する。
### 近日中（Medium）
1. docker0 がリンクダウンしている理由を確認し、意図しない停止であれば復旧する。
### 計画的に（Low / Info）
1. python プロセス（pid 13166）の CLOSE-WAIT 接続を継続監視し、再現するならソケット処理を修正する。
2. mDNS（5353）や CUPS が不要であれば無効化し、公開面を縮小する。
---
*本レポートは ubuntu-insights MCP による自動収集結果に基づく所見です。関連するファイアウォール・SSH等の指摘は「セキュリティ診断レポート」（security-report.md）を参照してください。*
レポートの出力内容を見ているだけでも勉強になります。pythonプロセスなどは、これまでほとんど意識したことがありませんでした。
おわりに
今回は先日IBM Bobを活用して開発したUbuntu向けMCPサーバーに、セキュリティーとネットワーク観点での診断を行うツールを新たに開発し、その使用感をIBM Bob、AWS Kiro、Claude Codeの3つのAIエージェントでの利用例を基にご紹介しました。
現在は自身のローカル環境のUbuntu Linuxでしか、当該MCPサーバーは導入してませんが、クラウド環境のUbuntu Linuxにも導入した場合には、どのような結果が見られるかをまた見てみたいと思います。
