Jul 22, 2026

07/22 夕方版 ダイジェスト

--- 以下、Copilotの今日のトピックス --->

◆ IT系ニュース（サイバー除く）

① AI投資競争が継続
  • MicrosoftはAI・クラウド需要を背景に大型成長を維持。
  • OpenAI関連投資利益も業績を押し上げ。 [microsoft.com], [microsoft.com]
② GoogleがGemini新モデル投入
  • Gemini 3.6 Flashなどの新モデル発表。
  • AI基盤競争はGoogle、Microsoft/OpenAI、Anthropic、Metaの4強構図が継続。 [aitoolsrecap.com]
③ 半導体・AIインフラ需要が依然強い
  • TSMC、SK Hynix、AI向けメモリ・GPU需要が継続。
  • AI関連設備投資が世界景気の下支え要因と評価。 [aitoolsrecap.com], [imf.org]

◆ サイバーセキュリティ主要トピック

① ServiceNow重大脆弱性の悪用報告
② Chromeが高深刻度脆弱性を修正
③ ランサムウェア被害拡大継続
投稿者 時刻: No comments:

Jul 21, 2026

OPNsenseに、後でUnbound DNSを導入する場合は

テスト前に、WireGuardのクライアント設定（confファイル）にも、Unbound DNSのIPを設定すべし。

OPNsenseの各種機能を順に試しながら Unbound DNSを導入していて
（Peerの設定変更は要らないと思い込んでいたり、大きな変更は後からで良いと思い込んでいると）
port 53/udpだけ OPNsenseに到達しない現象でハマるので、メモ。

--- 以下 Geminiの回答を編集した --->

結論、解決のための具体的アクション

Unbound DNS（例、10.0.0.1）経由で NextDNS のキャッシュ機能を利用できるようにするには、以下の手順で設定を変更してください。

Step 1: クライアント側（または OPNsense の Peer 設定）の DNS 変更

WireGuard クライアントの .conf ファイル（または自作ルータの WG 設定）内の DNS 項目を変更します。

Ini, TOML
[Interface]
...
# 変更前: DNS = 1.1.1.2
# 変更後: OPNsense の WireGuard IP を指定する
DNS = 10.0.0.1

Step 2: テストの実行

変更を反映（VPN再接続）させた後、クライアント PC から以下を実行します：

Bash

# 1. Unbound（10.0.0.1）宛ての 53/UDP 通信チェック
nmap -sU -p 53 10.0.0.1

# 2. OPNsense（10.0.0.1）を指定した名前解決テスト
nslookup google.com 10.0.0.1

これで、クライアント OS が 10.0.0.1 への 53/UDP 通信を「正当な DNS 通信」とみなし、パケットがトンネルを通過して OPNsense の WireGuard i/f（tcpdump）に届くようになります。

OPNsense 公式ドキュメントにおける位置づけ

OPNsense の公式ドキュメント（WireGuard Road Warrior Setup / Unbound Integration） には、まさにこの挙動に関連する非常に重要な注意書きが記載されています。

OPNsense Documentation Quote: "If using the peer generator and require Unbound DNS to serve names, fill the DNS server with the tunnel address (e.g. 10.0.0.1)." "Leave the DNS Server field blank... Otherwise WireGuard will overwrite OPNsense's DNS configuration."

OPNsense の設計として、「Unbound DNS を WireGuard クライアントに使わせたい場合は、WireGuard のクライアント設定（Peer/Interface）で配る DNS アドレスに、OPNsense のトンネル IP（10.0.0.1）を明示指定しなければならない」 と定められています。

まとめ

    1.1.1.2 以外の 53/UDP が通らなかった原因: WireGuard クライアント側で DNS = 1.1.1.2 を配布していたため、それ以外の IP 宛ての 53/UDP がクライアント側で排除されていた。

    対処法: WireGuard の配布 DNS を 10.0.0.1（Unbound が Listen している OPNsense のトンネル IP）へ差し替える。

投稿者 時刻: No comments:
ラベル:

Jul 18, 2026

OPNsenseに、CrowdSecを導入するには

--- 以下、GeminiとCopilotの組み合わせを編集した --->

OPNsense上なら、驚くほど簡単です。

1. プラグイン導入
System
 → Firmware
 → Plugins
で os-crowdsec をインストールします。CrowdSec公式では、CrowdSec本体・LAPI・Firewall Bouncerがまとめて導入されると説明されています。 [docs.crowdsec.net], [docs.crowdsec.net]
2. 動作確認
Services
 → CrowdSec
 → Overview
で
  • Log Processor
  • LAPI
  • Remediation Component
が起動していることを確認します。 [docs.crowdsec.net], [docs.crowdsec.net]
3. コミュニティ脅威情報を受信
初期状態でも、
  • SSH
  • OPNsense管理画面
などへの攻撃を監視し、
  • CrowdSecコミュニティの悪性IP情報
を受け取ってブロックし始めます。 [zenarmor.com], [homenetworkguy.com]
4. 効果確認
管理画面の
Services
 → CrowdSec
 → Decisions
で BAN されているIPを確認できます。 [docs.crowdsec.net]
貴方向けの最小構成
まずは
VPS(OPNsense)
+ WireGuard
+ CrowdSec
だけで十分です。
作業時間は10分程度、得られるものは
  • どこの国から攻撃が来るか
  • どんなブルートフォースが来るか
  • Threat Intelligenceがどう使われるか
の理解です。
その後で
Suricata
↓
Wazuh
↓
Security Onion
に進むと、自然にSOCの世界へ繋がります。CrowdSecは「最も軽量で効果が見えやすい次の一手」です。

投稿者 時刻: No comments:
ラベル:

Jul 10, 2026

著名人の暗号通貨

 --- 以下 Geminiの回答を抜粋・編集した --->

高市早苗首相の名前を冠した暗号資産「サナエトークン（SANAE TOKEN）」は、高市氏本人が関与を公式に否定したことで価格が暴落し、その後プロジェクトは中止されました。無登録業者による違法な販売の疑いや投資家からの損失相談が相次ぎ、現在も国会や金融庁で追及・調査が続けられる事態に発展しています。 [1, 2, 3, 4, 5]
具体的なニュース報道や国会での議論の様子については、以下の各リンクから詳細を確認できます。

トランプ氏の仮想通貨（WLFI）とは受益者構造が全く異なります。
トランプ氏のプロジェクトは本人が直接関与して公式に利益を得る構造ですが、サナエトークンは本人が関与を全面否定した「勝手に応援するトークン」でした。

1. トランプ氏のコイン（WLFI）の構造

  • 本人の直接関与: トランプ氏やその家族が立ち上げた公式プロジェクト（World Liberty Financial）です。
  • 明確な受益権: トランプ氏の企業が、トークン販売で得られる純収益の約75%を受け取る契約になっています。
  • 合法的なビジネス: 米国の規制に沿って、本人が直接利益を得るスキームとして運営されています。

2. サナエトークンの構造

  • 本人の関与はゼロ: 高市首相本人は「一切関与しておらず、承認もしていない」と完全否定しています。
  • 第三者による運営: 政治家本人に利益は入らず、発行元である民間の運営団体（NoBorder DAOなど）が資金を集める構造でした。
  • 違法性の疑い: 本人の許可なく名前を冠し、無登録で販売されたとして、金融庁や国会で問題視されています。
このように、トランプ氏は「本人が儲かる公式ビジネス」、サナエトークンは「本人の知らないところで第三者が資金を集めたトラブル」という違いがあります。

投稿者 時刻: No comments:

OpenVPN 2.7.5/2.6.21 リリース ─ 複数の脆弱性を修正 (07/05)

https://thinkit.co.jp/news/39340

『複数のセキュリティ問題と不具合を修正するパッチリリース。OpenVPN 2.7.5では7件、OpenVPN 2.6.21では6件のCVEに対応している。』

OPNsense環境では次のいずれかでバージョン確認可能
  1. GUIで　System → Firmware → Status
  2. SSH等シェルで /usr/local/sbin/openvpn --version
  3. pkg info | grep openvpn

OPNsenseは標準では「自動アップデート」ではなく、「更新確認は自動、適用は手動」が基本。
※ cronでopnsense-updateやpkg upgradeを起動すれば自動化可能だが、可用性喪失リスクがあり企業では一般的でない。

記事に挙がっているCVEを以下整理。OpenVPN 2.7.5/2.6.21では次の脆弱性が修正されています。 [thinkit.co.jp]
CVE
内容（要約）
CVSS
CVE-2026-12996
制御チャネル/認証パケット処理の use-after-free
CVSS v3.x 9.8 Critical（Tenable） [tenable.com], [tenable.com]
CVE-2026-13117
動的 tls-crypt 制御チャネル処理の use-after-free
CVSS v3.0 9.8 Critical [tenable.com]
CVE-2026-13122
auth-token によるサーバクラッシュ（DoS）
CVSS v4.0 5.9 Medium [app.opencve.io], [github.com]
CVE-2026-12932
tls-crypt-v2 クライアント鍵処理のメモリリーク
CVSS v3.x 9.8 Critical（Tenable） [tenable.com]
CVE-2026-13698
tls-crypt-v2 パケット処理のメモリリーク
CVSS v4.0 6.0 Medium [app.opencve.io], [cvefeed.io]
CVE-2026-11771
NTLMv2 プロキシ応答処理の 1-byte buffer overrun
公開CVSS未確認。Tenableでは Critical 扱いだがスコアは未表示。 [tenable.com], [tenable.com]
CVE-2026-13379
Windows DNS SearchList 設定破損（2.7.5のみ）
現時点で公開CVSS確認できず。 [thinkit.co.jp]

Known Exploited Vulnerabilities (KEV) Catalog について

結論として、
記事中の OpenVPN 関連 CVE は、現時点で CISA Known Exploited Vulnerabilities Catalog に掲載されていません。 [cisa.gov], [cisa.gov]
公開されたばかり（2026/7/1～7/6頃）であり、私が確認できた CVE-2026-13122 および CVE-2026-13698 についても KEV: No と明記されています。 [app.opencve.io], [app.opencve.io]

OPNsense利用者向けの実務的な見方

貴方の環境のように OPNsense 上で OpenVPN サーバを使用している場合、

  • KEV掲載なし

  • 攻撃コード公開情報も未確認

  • ただし use-after-free 系（CVE-2026-12996, CVE-2026-13117）は CVSS 9.8

という状況です。 [tenable.com], [tenable.com]

そのため、

「緊急パッチレベルではないが、次回メンテナンスを待たず早めに更新を検討」

が妥当な判断と思われます。特に OpenVPN をインターネットへ公開しているサーバでは優先度は比較的高めです。 [thinkit.co.jp], [tenable.com], [tenable.com]

なお、OPNsense 26.1 が実際にどの OpenVPN バージョンを搭載しているかは、GUIの

System → Firmware → Packages

または SSH で

openvpn --version

で確認できます。現在の OPNsense リポジトリに 2.6.21 が取り込まれたかどうかも併せて確認するとよいでしょう。


←--- 以上、CopilotとGeminiの回答を合体・編集した ---


投稿者 時刻: No comments:

OPNsense バックアップ

 --- 以下 CopilotとGeminiのコメントを合体・編集 --->

OPNsenseの原状復帰に関して、OPNsense自身のインストーラに「既存設定を自動検出して引き継ぐ」機能は、通常期待しない方がよいです。

その代わり、OPNsenseでは 設定バックアップ (config.xml) を保存し、再インストール後に復元する のが正式な運用です。 [docs.opnsense.org]
VPS上の個人利用なら、
  1. 更新前に設定バックアップ取得
  2. OPNsense更新
  3. 問題発生時はVPSプロバイダのコンソール利用
  4. 最悪はOPNsense再インストール
  5. 保存しておいた config.xml を復元
という手順になります。

更新前に最低限やっておくと安心

GUIから
System
  → Configuration
      → Backups
で設定ファイルをダウンロード。
※　通常は以下の場所に保存されています。
/conf/config.xml
数MB程度の1ファイルに
Firewall Rules, NAT, OpenVPN, WireGuard, Unbound DNS, DHCP, VLAN, Gateway, Routing
などほぼ全ての設定が入っています。

過去世代は次のように保存されています。
　　/conf/backup/config-1748500000.xml
　　/conf/backup/config-1748600000.xml

貴方の現在の用途なら


①config.xml バックアップ　　②VPSスナップショット
の2つを取ってから更新が実用的です。
1人利用のVPNサーバなら、これだけでかなり安心して OpenVPN のセキュリティアップデートを追いかけられると思います。

私が前回書いた

「カスタム証明書ファイルは config.xml に含まれない場合がある」

は、OPNsense標準機能だけを使っている場合には、やや慎重すぎる表現でした。

実は OPNsenseのCA・証明書・秘密鍵の多くは config.xml に格納されています。

OpenVPNの場合

例えば
System
 → Trust
   → Authorities
   → Certificates
で管理している
  • CA証明書
  • サーバ証明書
  • クライアント証明書
  • 対応する秘密鍵
は、通常は config.xml に保存されます。
したがって、
<ca>
...
</ca>

<cert>
...
</cert>
といった形でバックアップされます。
このため、
  1. config.xml保存　　
  2. 同じ版数のOPNsense再インストール　　
  3. config.xml復元
でOpenVPNが再開するケースは非常に多いです。

WireGuardの場合

WireGuardの
  • サーバ秘密鍵　　
  • サーバ公開鍵　　
  • Peer設定
も通常は設定データとして保存されています。
したがって、
VPN
 → WireGuard
で作成した設定も、通常は config.xml 復元対象です。

私がより心配するもの

実は証明書よりも、
プラグイン
例えば
os-wireguard
os-ddclient
os-acme-client
os-crowdsec
などです。
config.xmlは復元されても、
プラグインが未インストールだと設定を活用できません。

ACME証明書

Let's Encryptを使う場合、
  • ACMEプラグイン設定
  • 発行済み証明書
は復元できることが多いですが、
再発行した方が早いケースもあります。

手作業で配置したファイル

例えばSSHで
/usr/local/etc/
などに
  • 独自スクリプト
  • 独自証明書
  • 独自鍵
を置いた場合、
config.xmlとは別管理です。
これは別途バックアップが必要です。

貴方の「漏れなく救出できるか」という観点

SSHで確認できます。
例えば
grep -i "<private>" /conf/config.xml
や
grep -i "<cert>" /conf/config.xml
を実行すると、
Base64文字列が大量に見えるはずです。
それが証明書や鍵です。

実務的なおすすめ

VPS更新前なら私は次の3点を取ります。
① config.xml
cp /conf/config.xml /root/config.xml.backup
② プラグイン一覧
pkg info > /root/pkg-info.txt
③ VPSスナップショット
VPS業者機能
この3つがあれば、
  • OpenVPN証明書　　
  • WireGuard鍵　　
  • Firewallルール　　
  • NAT　　
  • DNS　　
  • DHCP
まで含めて、かなり高い確率で元に戻せます。
むしろ貴方のシナリオで最大のリスクは、
「config.xmlを取らずに再インストールすること」ではなく、「新しいOPNsenseでプラグイン構成を忘れること」
だと思います。
ですので、今のうちに一度SSHで
pkg info
を実行し、結果を保存しておくと安心です。これは昔のSolarisでいう「インストール済みパッケージ一覧の退避」に相当します。
投稿者 時刻: No comments:
ラベル:

OPNsense バックアップ cronで自動化

--- 以下Copilotの解説 --->

OPNsenseの標準機能（Cron）を組み合わせることで、「手動バックアップ後に自動でマイナーアップデートを適用する」という運用が可能です。 [1, 2]

ただし、標準のCronジョブには「リリースから正確に1週間後」をシステム単体で自動判定するロジックはありません。そのため、実務上は「毎週特定の曜日（リリースから概ね1週間が経過するタイミング）に自動実行するスケジュールを組む」という方法でご要望のサイクルを実現します。 [1, 3]
OPNsenseのマイナーパッチは、通常「木曜日」にリリースされることが多いため、ここでは「翌週の木曜日」に自動更新をかける設定手順を解説します。

⚙️ 設定手順：毎週自動マイナーアップデートの構築

OPNsenseの管理画面（WebUI）から設定を行います。 [4]

◆ 自動更新タスク（Cron）の登録

  1. 管理画面の [System] > [Settings] > [Cron] に移動します。
  2. 画面右下の 「＋」（追加）ボタン をクリックします。
  3. 以下の通りパラメータを入力します。 [2, 3]
設定項目 [1, 3, 5, 6]
入力値
意味
Minutes
0
0分に実行
Hours
4
深夜 4:00 に実行（影響の少ない時間帯）
Days
*
毎月すべての日にち
Months
*
毎月
Days of week
4
毎週木曜日（0=日, 1=月... 4=木）
Command
Automatic firmware update
自動ファームウェアアップデートを実行
Description
Weekly Auto Minor Update
任意の識別用メモ
  1. 「Save」 をクリックして保存します。
  2. 保存後、Cronページ下部にある 「Apply」 ボタンを必ずクリックして設定を反映させます。 [2]
💡 重要仕様：メジャーバージョンアップはスキップされます
OPNsenseの標準コマンド Automatic firmware update は、マイナーパッチ（例: 25.7.1 → 25.7.2）のみを自動適用し、再起動までを行います。ベースOSの変更を伴う「メジャーアップデート（例: 25.7 → 26.1）」はこのタスクでは実行されず、必ず手動でのトリガーが必要になるため、意図せずシステムが致命的に大破するリスクは最小限に抑えられます。 [5, 7, 8]

🛡️ 運用ルール（手動バックアップのタイミング）

「放置による侵害リスク」を防ぐための現実的な運用フローです。
  1. バックアップのタイミング:
    自動更新が「毎週木曜日の深夜4時」に走るため、週に1回、水曜日の夜などに管理画面（[System] > [Firmware] > [Status]）を開き、パッチが来ているか確認しつつ、[System] > [Configuration] > [Backups] から設定のXMLファイルをダウンロードしておきます。
  2. もしバックアップを忘れて自動更新されたら:
    「自動停止リスクは受容する」とのことですので、そのまま木曜朝を迎えます。万が一不具合で通信が止まっていた場合は、コンソール接続等から前回の手動バックアップをインポートして復旧させます。
この設定を進めるにあたり、以下の点についてサポートが必要であればお知らせください。
  • 毎週木曜日以外の特定の曜日や時間帯にスケジュールを変更したいですか？
  • 万が一、自動更新後にネットワークが不通になった場合のコンソールからの復旧手順を確認しておきますか？


投稿者 時刻: No comments:
ラベル:
Subscribe to: Posts (Atom)