# JPCERT定点観測レポート2026年1-3月｜23/TCP Telnet依然1位、自社で今すぐやるべきポート監査手順
JPCERT/CCが2026年5月、インターネット定点観測システム「TSUBAME」による2026年1-3月期の観測レポートを公開しました。観測ポートTOP5の顔ぶれは大きく変わらず、依然として23/TCP Telnetが最多スキャン対象です。一方でイラン国内のインターネット接続制限・軍事作戦の影響で送信元ホスト数が一時的に急減するという、地政学要因がポートスキャン観測に直接現れる結果も記録されました。
この記事では、レポートの観測結果を要約したうえで、Linux／Windows／クラウドの各環境で「自社の23・3389・22番ポートが意図せず外部公開されていないか」を実際に確認する具体的な手順を解説します。原文レポートの数値は[JPCERT/CC TSUBAMEレポート2026年1-3月](https://www.jpcert.or.jp/tsubame/report/report202601-03.html)に依拠しています。
## JPCERT/CC定点観測レポート2026年1-3月のハイライト
JPCERT/CCのインターネット定点観測システム「TSUBAME」は、複数のIPアドレス空間に設置したセンサーで、インターネット上のスキャンパケットを継続的に記録しています。今回公開されたレポートは2026年1月1日から3月31日までの3か月間の集計です。
**観測ポートTOP5（宛先ポート別）**
| 順位 | ポート | サービス | 前四半期 |
|—|—|—|—|
| 1 | 23/TCP | Telnet | 1位 |
| 2 | 443/TCP | HTTPS | 3位 |
| 3 | 22/TCP | SSH | 4位 |
| 4 | 80/TCP | HTTP | 2位 |
| 5 | 8080/TCP | HTTP-Proxy系 | 5位 |
23/TCP Telnetが連続で1位を維持しており、IoTデバイスを狙ったMirai系・Aisuru系ボットネットによる既定認証情報の探索が継続している実態が読み取れます。443/TCPと22/TCPが順位を1つずつ上げ、Webサーバとリモート管理面の探索が増加傾向にあります。
**送信元地域TOP5**
| 順位 | 国 | 前四半期 |
|—|—|—|
| 1 | 米国（US） | 1位 |
| 2 | オランダ（NL） | 4位 |
| 3 | ブルガリア（BG） | 2位 |
| 4 | ドイツ（DE） | 3位 |
| 5 | 中国（CN） | 7位 |
米国が首位なのはクラウドホスティング事業者の所在国としての構造的要因が大きく、実際の攻撃者の所在地ではない点に注意が必要です。中国が7位から5位へ上昇している点も、SOC運用者として無視できない変化です。
**地政学要因による送信元ホスト数の急減**
レポートで特に注目されているのが、イラン関連の動向です。2026年1月8日にイラン国内でインターネット接続制限が発生し、TCP SYNパケットの送信元ホスト数が大きく減少した様子がTSUBAMEでも捉えられました。Cloudflareの観測結果とも同期しています。さらに2月28日以降の軍事作戦と並行し、通常時150～200ホスト規模で観測されていたイラン由来のスキャン送信元が、約10ホスト前後の極端な低水準まで落ち込みました。
つまり「ポートスキャンは純粋な技術現象ではなく、地政学・国家政策とも連動する」という事実が、今回のレポートで改めて明確になったわけです。
## 観測上位ポート別の脅威動向解説
観測TOP5のポートそれぞれが、なぜ狙われ続けているのかを整理します。
**23/TCP Telnet — IoTボットネットの主戦場**
Telnetは通信内容が暗号化されない設計のため、現代の業務システムでは原則使われないプロトコルです。しかし家庭用ルーター・ネットワークカメラ・産業用機器・古いL2スイッチなどでは、未だに有効化されたまま出荷・運用されている個体が大量に存在します。Mirai系のソースコードが2016年に公開されて以降、Aisuruを含む派生ボットネットがTelnetポートをスキャンし、admin/admin・root/root等の既定認証情報を試行する手法を継続しています。
**443/TCP HTTPS／80/TCP HTTP — Webアプリ層の脆弱性探索**
Webサーバ向けスキャンは「ポート空いてるかの確認」ではなく、すでに「特定のCMS・特定のCVEを叩く」段階まで進化しています。WordPressのwp-admin、PHPMyAdmin、Apacheの旧バージョン特有のパス、nginxの設定ミス由来のステータスコード差分などを連続的にプローブします。
**22/TCP SSH — クラウド時代の標的**
クラウド上でEC2・GCE等を立ち上げると初期状態で22/TCPがグローバルに開いているケースが多く、ボットネットの絶好の標的です。fail2banやKey認証強制が未設定だと、数時間で数万回の認証試行を受けることもあります。
**8080/TCP — プロキシ・代替Web・管理画面**
8080番は管理コンソール（Tomcat・Jenkins・各種BIツール）や代替Webサーバとして使われることが多く、認証画面が露出していれば総当たり攻撃の対象になります。
“`bash
# 自社IPでTelnet（23/TCP）が外部から見えるか即チェック
nmap -Pn -p 23 your-global-ip-here
“`
## 自社で実施すべきポート閉鎖確認手順（Linux／Windows）
レポートを読んで終わらせず、自社環境の23・22・3389・8080・80・443の状態を実測する手順を示します。
**Linuxサーバでの確認手順**
リッスンポート一覧の取得には、ssコマンドが推奨です。netstatは多くのディストリで非推奨化されています。
“`bash
# リッスン中の全TCPポート（プロセス名付き）
sudo ss -tlnp
# 23/TCP, 22/TCP, 3389/TCP が含まれていないか確認
sudo ss -tlnp | grep -E ‘:(23|3389|8080) ‘
“`
23/TCPがリッスンしていた場合、利用していなければ即時停止します。
“`bash
# telnetdが入っているか確認
dpkg -l | grep -i telnetd # Debian/Ubuntu
rpm -qa | grep -i telnet # RHEL/AlmaLinux/Rocky
# 停止・無効化
sudo systemctl stop inetd.service 2>/dev/null
sudo systemctl disable inetd.service 2>/dev/null
sudo apt purge telnetd -y # Ubuntu
sudo dnf remove telnet-server -y # RHEL系
“`
firewalldで穴を塞ぐ場合の例です。
“`bash
sudo firewall-cmd –list-all
sudo firewall-cmd –remove-service=telnet –permanent
sudo firewall-cmd –reload
“`
iptables直叩き環境では明示的にDROP化します。
“`bash
sudo iptables -A INPUT -p tcp –dport 23 -j DROP
sudo iptables-save | sudo tee /etc/iptables/rules.v4
“`
**Windowsサーバでの確認手順**
3389/TCP RDPが外部公開されていないかを確認します。RDPはレポートのTOP5には入っていませんが、ランサムウェア攻撃の主要侵入経路であり、JPCERTも繰り返し注意喚起しています。
“`powershell
# リッスン中のポート一覧
Get-NetTCPConnection -State Listen | Format-Table LocalAddress,LocalPort,OwningProcess
# 3389/TCPがリッスンしているか
Get-NetTCPConnection -State Listen -LocalPort 3389
“`
外部からの3389アクセスを遮断する場合、Windows Defenderファイアウォールで以下を実行します。
“`powershell
# 既存のRDP受信規則をすべて無効化
Get-NetFirewallRule -DisplayGroup “リモート デスクトップ” | Disable-NetFirewallRule
# 業務IPからのみ許可するなら別途RemoteAddressで限定
New-NetFirewallRule -DisplayName “RDP-OfficeOnly” -Direction Inbound `
-Protocol TCP -LocalPort 3389 -RemoteAddress 203.0.113.0/24 -Action Allow
“`
**外部からの実測（最重要）**
サーバ内部から見たリッスン状態と、外部から実際に到達できるかは別問題です。NATやセキュリティグループの設定ミスで「閉じたつもりが開いていた」事故は頻発します。必ずグローバルIPから自社IPへnmapを撃って実測します。
“`bash
# 外部のVPS等から自社のグローバルIPへ
sudo nmap -Pn -sS -p 22,23,80,443,3389,8080 your-global-ip-here
“`
## クラウド環境のセキュリティグループ監査（AWS/Azure）
オンプレ機器のポートを閉じてもクラウド上で同じ穴を開けていれば意味がありません。AWS・Azureそれぞれの監査手順です。
**AWS — セキュリティグループ全件チェック**
23/TCP・3389/TCPを0.0.0.0/0に開放しているSGを抽出します。
“`bash
# AWS CLIで全リージョン・全SGをスキャン
aws ec2 describe-security-groups –query \
‘SecurityGroups[?IpPermissions[?ToPort==`23` && IpRanges[?CidrIp==`0.0.0.0/0`]]].[GroupId,GroupName,VpcId]’ \
–output table
# 3389の場合
aws ec2 describe-security-groups –query \
‘SecurityGroups[?IpPermissions[?ToPort==`3389` && IpRanges[?CidrIp==`0.0.0.0/0`]]].[GroupId,GroupName,VpcId]’ \
–output table
“`
実運用ではAWS Configルール `restricted-ssh`・`restricted-common-ports` を有効化し、非準拠SGを継続検知する構成が現実解です。
**Azure — ネットワークセキュリティグループ確認**
“`bash
# 全NSGで22/3389/23のAny許可ルールを抽出
az network nsg list –query \
“[].{Name:name,RG:resourceGroup,Rules:securityRules[?destinationPortRange==’3389′ && sourceAddressPrefix==’*’]}” \
-o table
“`
クラウド監査の鉄則は「**例外申請のないAny許可は即時剥がす**」です。「いつ・誰が・何のために」開けたかを台帳化していない開放ルールは、99%が放置です。
## 検知ルール・SIEM相関活用
ポートを閉じる前提のうえで、SIEM／IDS／NDRで「閉じたはずのポートに対するスキャン痕跡」を可視化する設計が次の一手です。
**Suricataで23/TCPスキャンを検知**
“`
alert tcp $EXTERNAL_NET any -> $HOME_NET 23 (msg:”INET-PROBE Telnet scan inbound”;
flow:to_server; flags:S; threshold:type both, track by_src, count 5, seconds 60;
classtype:attempted-recon; sid:9000023; rev:1;)
“`
このルールは「1分間に5回以上、外部から23/TCPへSYNが来たIP」を1件のアラートに集約します。閾値はノイズ量を見て調整します。
**SIEM相関の設計指針**
– 23/22/3389/8080への外部発信SYNが、社内端末から流れていないか（侵害された内部端末がスキャナ化していないかの早期検知）
– ファイアウォールDROPログとIDSアラートのIPを突合し、攻撃の継続性を時系列で可視化
– TSUBAMEレポートのTOP5ポートを「最低限の常時監視対象」として固定化
JPCERTのレポートは年4回更新されます。社内ルールに「四半期レポート公開後30日以内にTOP5ポートの自社開放状況を再点検」のサイクルを組み込むのが、運用としての落とし所です。
実務でポート監査・SOC運用を担当する方には、ネットワークセキュリティの体系書を一冊手元に置くと判断が早くなります。
マスタリングTCP/IP 情報セキュリティ編 第2版（オーム社）[PR] — TCP/IP層別の攻撃と防御をきれいに分けて解説しており、ポート別脅威の理解にそのまま使えます。
## FAQ（よくある質問）
**Q1. TSUBAMEレポートはどこで読めますか？**
A. JPCERT/CCの公式サイト [https://www.jpcert.or.jp/tsubame/report/](https://www.jpcert.or.jp/tsubame/report/) で四半期ごとに公開されています。最新の2026年1-3月版は https://www.jpcert.or.jp/tsubame/report/report202601-03.html で全文を読めます。
**Q2. なぜTelnet（23/TCP）が依然1位なのですか？**
A. IoTデバイス（家庭用ルーター・ネットワークカメラ・産業機器）でTelnetが既定有効のまま出荷されている個体が大量に残存しており、Mirai系・Aisuru系のボットネットが既定認証情報スキャンを続けているためです。
**Q3. 米国が送信元1位ですが、米国の攻撃者ですか？**
A. 違います。米国はクラウドホスティング事業者（AWS・Azure・GCP等）の所在国としての構造的1位です。攻撃者は世界各国からVMを借りて発信源にしています。SOC運用では「送信元国の地政学解釈」より「ASN単位の遮断判断」を推奨します。
**Q4. 自社で23/TCPは閉じているはずです。それでも確認すべきですか？**
A. 必須です。内部から `ss -tlnp` で閉じて見えても、外部からのnmapで開いていたケースが事故事例として多数あります。NAT・SG・ロードバランサ・古い検証環境などの設定ミスを必ず実測してください。
**Q5. SIEMがない小規模組織は何から始めるべきですか？**
A. ① firewalldログをjournald経由で7日保持、② 月次でssコマンドのリッスンポート一覧を社内Wiki等に記録、③ TSUBAMEレポート公開時に開放ポートを再点検、の3点だけで初期態勢になります。SIEM導入は次フェーズで構いません。
**Q6. RDP（3389/TCP）はレポートのTOP5に入っていないのに、なぜ閉じる必要があるのですか？**
A. JPCERTのTOP5には入っていませんが、RDPはランサムウェア攻撃の主要侵入経路としてJPCERTが過去複数回注意喚起しています。観測ランキングと実害ランキングは別物として運用してください。
**Q7. ポートを閉じる以外に対策はありますか？**
A. ① 必要なポートでも送信元IPを業務拠点・VPNゲートウェイに限定、② パスワード認証廃止と鍵認証強制、③ fail2ban等で異常試行を自動遮断、④ MFA導入、の4点が定石です。
## まとめ — レポートを読むだけで終わらせない
JPCERT/CCの定点観測レポート2026年1-3月版は、23/TCP Telnetが依然1位という事実と、地政学的要因による送信元ホスト数の急減という新しい観測ハイライトを示しました。レポート読了で終わらず、自社の23・22・3389・8080番ポートの実態を外部からのnmap実測まで含めて確認することが、実務担当者の最低ラインです。
**自社環境チェックリスト（即実行可能）**
以下5項目を今日中に確認してください。
– [ ] グローバルIP宛にnmap -p 22,23,80,443,3389,8080を外部から撃ち、想定外の開放がないか実測
– [ ] AWS/Azure全SGで0.0.0.0/0開放の23・3389を抽出し、必要性を再確認
– [ ] Linux各サーバで `sudo ss -tlnp | grep -E ‘:(23|3389) ‘` の結果が空であることを確認
– [ ] WindowsサーバでGet-NetTCPConnection -State Listen -LocalPort 3389の結果と業務要件の整合性を確認
– [ ] 四半期ごとのTSUBAMEレポート公開（年4回）を社内カレンダーに登録、公開後30日以内の再点検をルーチン化
ポート監査・SOC運用・脆弱性管理を体系的に学びたい方は、当社の無料メルマガで実務手順とJPCERT等の一次情報の読み方を継続的に配信しています。
セキュリティマスター.JPの実務メルマガはこちらから登録できます。
ネットワークセキュリティ書籍の決定版もあわせて確認してください。
情報処理安全確保支援士 教科書＋過去問（翔泳社）[PR] — 高度試験区分の体系書で、現場運用にもそのまま転用できる情報セキュリティ全体像が一冊に収まっています。
