Showing posts with label OPNsense. Show all posts
Showing posts with label OPNsense. Show all posts

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

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:
ラベル:

Jul 4, 2026

メモ、ホームユースのファイアウォール３選

アンチウイルスメーカーの家庭用ルータが手軽だが、出先での通信保護も必要なため、対象外とした。

既存環境（家庭内デバイスを丸ごとVPN経由のVPSに収容し、出口対策・境界防御を固めるというアーキテクチャ）の更新検討目的でのメモ。質問先AIによって回答が異なる点も興味深い。

◆ おすすめのファイアウォール（UTM/IDS）3選

Linuxでの構築経験があり、VPN（WireGuardやOpenVPN）と組み合わせる前提で、上記の「Webフィルタリング」「IDS/IPS」を強力にカバーできるソリューションを3つ厳選しました。

① opnSense（または pfSense）

Linux/BSDベースの本格派オープンソースUTM
「自宅ルータからVPSにVPNを張る」という構成において、VPS側のOS自体をこれに置き換える（またはKVM等の仮想化上で動かす）場合のファーストチョイスです。
  • 特徴: GUIが非常に洗練されており、プラグイン形式で機能を拡張できます。Linuxのiptablesをポチポチ叩く不毛さから解放されます。
  • なぜおすすめか（脅威への対応）: 「Zenarmor（旧Sensei）」という次世代FW（NGFW）プラグインを導入することで、HTTPSデコード（SSL復号）を行わずとも、AIベースでトラフィックの挙動（レイヤー7）を解析し、フィッシングサイトやマルウェアのC2サーバへの通信をブロックできます。また、IDS/IPS（Suricata）も標準搭載しています。

② CrowdSec + nftables (または UFW) + Pi-hole（構成案）

現代風Linuxエンジニア向け：協調型防御 ＆ DNSフィルタリング
「OSは使い慣れたUbuntuやDebianがいい」という場合に、既存のLinux FWに現代的なセキュリティレイヤーを肉付けする組み合わせです。
  • 特徴: CrowdSecは「令和版Fail2ban」とも呼ばれるセキュリティツールです。VPSのログ（SSHやVPNの接続試行）を監視し、怪しい挙動のIPを自動検知するだけでなく、世界中のCrowdSecユーザーが検知した悪質なIPリスト（インテリジェンス）をリアルタイムに共有され、自動で遮断してくれます。
    注、DNSによる防御を強化するきっかけとして、様々なログを解析し、協調分散してDNSBL（DNS Black List）に反映する仕掛け。
    注、OPNsenseにCrowdSecプラグインを組み込む方法もポピュラーかつ公式推奨らしい。
  • なぜおすすめか（脅威への対応）: VPS側で待ち受けるVPNポートへの執拗な攻撃（スキャンやDoS）をCrowdSecで自動防御しつつ、内部からのフィッシング対策としてVPS上に「Pi-hole」や「AdGuard Home」を立ててDNSフォワーダとします。これにより、危険なドメインへのアクセスをDNSレベルで実質100%シャットアウトできます。労力に対して最も費用対効果（防御効果）が高いLinux構成です。

③ Sophos Firewall Home Edition

商用グレードの次世代FWを家庭利用で無償運用
エンタープライズ領域で使われるガチガチの次世代ファイアウォール（NGFW）ですが、家庭用（非商用・4コア/6GB RAMまで）であれば無料で全機能が使えます。（※Intel/AMD系のx86_64アーキテクチャのVPSが必要です）
  • 特徴: 企業のセキュリティ部門が使う管理画面そのものです。アプリケーション制御、Webフィルタリング、IPS、サンドボックス（一部制限あり）がオールインワンで提供されます。
  • なぜおすすめか（脅威への対応）: ご指摘の「HTTPSデコードの難しさ」に対し、Sophosは「高度なWeb保護（カテゴリベースのURLフィルタリング）」を標準で持っているため、暗号化された通信であっても、接続先のドメインやIPの評判（レピュテーション）からフィッシングや不正サイトへのアクセスを強力に防御します。

◆ 結論：どれを選ぶべきか？

  • ネットワーク全体の管理をGUIでスマートに一元化したい
    👉 opnSense が最もバランスが良く、拡張性（ZenarmorによるL7防御）も高いです。
  • Linux（Ubuntu等）のベースは崩さず、最小限の労力で最大の効果を得たい
    👉 CrowdSec ＋ DNSフィルタリング（Pi-hole等） の組み合わせ。現代の「人間系脆弱性」に対してはDNSブロックが最も手軽で強力です。
  • エンタープライズ品質の「脅威インテリジェンス」を無料で振りかざしたい
    👉 Sophos Firewall Home Edition。設定の難易度は高めですが、防御力は群を抜いています。
ご自身のLinuxスキルの高さを活かすのであれば、まずは ②（Ubuntu/Debian + CrowdSec + Pi-hole等によるDNSブロック） あたりからスモールスタートされると、運用負荷も低く、ご認識の「労力の割に……」を良い意味で裏切る高い効果を実感できるかと思います。
← ← ← 以上 Gemeini, ... 以下 Copilot による → → → 

VPS上ファイアウォールのお薦め3選と、脅威認識の検証

まずご認識の妥当性を最新の脅威データで検証し、そのうえでVPSに載せる前提でのお薦めを3つ、目的別にご提示します。

1. ご認識の妥当性判断

  • 「NGFW以前の防御法（L3/L4のポート開閉細設定）に時間をかけない」判断は正しい一方で、FW製品選定は"DNS/URL/L7フィルタと脅威インテリの取り込みやすさ"で選ぶ方向に軸を移すのが2026年の最適解です。

2. お薦めファイアウォール3選(VPS運用前提)

🥇 ① OPNsense(第一推奨・現行構成の継続強化)
  • 理由: WireGuard/IKEv2 ネイティブ、UIモダン、FreeBSD派生のセキュリティ更新が早い。何より Zenarmor(旧Sensei)プラグインでL7アプリ制御+クラウド脅威インテリ、SuricataでIDS/IPSが標準搭載、CrowdSecプラグインで協調ブロックリストが使え、「人間系脆弱性を突く出口通信」を止める構成が最も組みやすい。 [opensource...curity.net], [diymediaserver.com] [sourceforge.net], [slashdot.org]
    注、Suricataはデコード負荷が重くVPSでは辛い。MACアドレスで除外する仕掛けもあるが、まずは「無し」か、せいぜいスマホ・タブレット・PCに限って開始すべし。
  • VPSでの相性: KVMベースのVPS(1〜2 vCPU/2GB RAM)で十分動作。
  • 脅威認識との整合: DNSフィルタ(Unbound + Adguard風ブロックリスト)を組めば、フィッシング/C2ドメインを名前解決段階で遮断でき、EDR無し家庭環境の弱点を実質補えます。 [cyberpress.org]
  • 既に導入済みなら、追加すべきは: ① Zenarmor無償版、② CrowdSec、③ ブロックリスト連携(NextDNS/Quad9をリゾルバに)。
🥈 ② pfSense CE / pfSense Plus(安定性重視のセカンドチョイス)
  • 理由: FreeBSDベース、実運用歴が最も長く、商用機と同等の実績。「一度組んだら数年触らず安定運用したい」ケースに最適。 [opensource...curity.net] [jisaku.com]
  • VPSでの相性: クラウド公式イメージが揃い、Netgate公式のクラウドテンプレートあり。
  • 注意点: ここ数年、機能の一部が **pfSense Plus(有償)**側に寄っており、Netgateの方針変更リスクが指摘されています。WireGuardは長らくプラグイン扱いで、更新頻度もOPNsenseに劣ります。 [opensource...curity.net], [diymediaserver.com] [diymediaserver.com]
  • 選ぶなら: 業務併用でサポート契約したい/教科書的なドキュメントを重視する場合。
🥉 ③ VyOS(CLI/IaC志向・軽量VPS向け)
  • 理由: DebianベースのルータOSにFW機能を後付けした設計。**設定がテキスト(commit/rollback可)**でGit管理でき、Ansible/Terraformとの親和性が高い。VPSで最小リソース(1 vCPU/1GB)でも安定します。 [blog.atomi...etworks.co]
  • 脅威認識との整合: GUI操作を捨てる代わりに、設定の再現性・監査可能性が最高クラス。Linux でのFW構築経験があれば学習コストは低いはずです。
  • 弱点: IDS/IPS・DNSフィルタは自前で組む必要あり(Suricata別途、Pi-hole/AdGuard Homeを別コンテナで併設が定番)。「UIぽちぽち」で L7 制御まで完結させたいなら OPNsense、「コードで管理したい」なら VyOS、が住み分けです。 [blog.atomi...etworks.co]

3. 現構成への実務的な追加提案(EDR無しの穴を埋める)

ご認識のとおり、家庭ではEDR/HTTPSインスペクションは現実的でないため、"入口を絞る"より"出口(egress)を絞る" に投資配分を寄せるのが2026年の合理解です。OPNsense 導入済みの前提で、以下3点を積むと費用ほぼゼロで人間系脅威に対する耐性が段違いになります:
追加レイヤ
具体策
効果
DNSフィルタ
Unboundで**NextDNS / Quad9 / Cloudflare Family (1.1.1.3)**を上流に。無償枠で悪性ドメイン・フィッシングを名前解決層で遮断 [cyberpress.org], [comparitech.com]
フィッシングURLのクリック事故を"名前が引けない"段階で無効化
CrowdSec プラグイン
OPNsense公式リポジトリから導入。世界中のノードのブロックリストを取り込み [slashdot.org]
エッジ機器狙いのブルートフォース/スキャンを協調防御
VPS側SSHの多要素化
fail2ban + 公開鍵限定 + 管理UIをTailscale/WireGuard越しのみに
Check Point 2026が警鐘を鳴らす「エッジ機器そのものの侵害」 [research.c...kpoint.com]を回避
まとめ
  • 「人間系が主流」、「家庭でL3/L4細設定はROI低い」は妥当。脆弱性悪用は増、「エッジ機器自体が標的化」 。
  • 3選は ① OPNsense(推奨)/② pfSense(安定)/③ VyOS(IaC) 。既に OPNsense 26.1 導入中であれば、製品変更よりも "DNSフィルタ + CrowdSec + 管理面の堅牢化" を積む方が投資対効果が高い構図です。
投稿者 時刻: No comments:
ラベル:
Subscribe to: Posts (Atom)