Linux

WireGuard に接続した後は、内部ドメインだけをトンネル経由の DNS で照会し、それ以外のドメインでは引き続きパブリック DNS を使用したい場合があります。systemd-resolved を使用している Linux システムでは、DNS ルーティングドメインを直接設定し、wg-quick の PostUp で自動的に適用できます。追加の DNS 転送サービスをインストールする必要はありません。 ...

バイパスルーティングとして使う Armbian 上で、sing-box と WireGuard を同時に稼働させている。このルーター自身は社内ドメインを解決できるのに、その IP を DNS サーバーに指定した下流クライアントは毎回タイムアウトする。原因は DNS のマッチングルールではなく、sing-box が上位 DNS へ送るトラフィックが誤った出力インターフェースを選んでいたことにあった。 本稿のアドレスはすべて書き換えた架空の値であり、実際のネットワーク設定ではない。プライベートネットワークのトポロジ関係とプロトコルの挙動はそのまま保持している。 トポロジと症状 役割 例示アドレス 用途 下流クライアント 192.168.10.20 DNS クライアント バイパスルート LAN 192.168.10.254 / eth0 sing-box DNS の待ち受けアドレス バイパスルート WireGuard 10.77.0.11 / wg0 トンネルクライアント 社内 DNS 10.77.0.1:53 WireGuard ピア側の DNS トポロジは次の構成になる。 クライアント 192.168.10.20 │ DNS クエリ ▼ バイパスルート 192.168.10.254:53 (sing-box DNS 受信) │ 期待: wg0 から 10.77.0.1:53 へ問い合わせ ▼ WireGuard ピア側 DNS 10.77.0.1:53 社内テストドメインは service.home.arpa（例示）を使用した。観測された症状は以下のとおり。 ...

Armbian に sing-box TUN をデプロイした後、少し分かりにくい問題が発生しました：IPv6 の ping は通るのに、auto_redirect を有効化すると IPv6 の HTTPS 接続がタイムアウトする的情况です。 调查结果、障害の原因は IPv6 の公網ルートやプロキシノードではなく、Linux のループバックインターフェース lo に ::1/128 アドレスが存在しないことでした。本稿では、その切り分け Processes .Ordinal and 修正方法を記録します。 環境 Linux：Armbian、ARM64、6.18 系カーネル sing-box：1.14.x ネットワーク管理：Netplan + NetworkManager 透過プロキシ：TUN、auto_route: true、auto_redirect: true IPv6：上位ネットワークから自動設定され、インターフェースにはグローバル IPv6 アドレスと RA によるデフォルトルートが設定済み プライバシーを保護するため、実際の公衆アドレス、MAC アドレス、ルーターアドレス、ドメイン名、およびカスタム内部ルーティングテーブル番号は省略しています。以下の例にある ULA アドレスとテスト対象は説明용です。 障害的现象 IPv6 HTTPS を直接テストします。 curl --noproxy '*' -6 -v --connect-timeout 5 \ --resolve 'cloudflare.com:443:[2606:4700::6810:85e5]' \ https://cloudflare.com/ sing-box を有効化した後： * Trying [2606:4700::6810:85e5]:443... * Connection timed out after 5002 milliseconds curl: (28) Connection timed out 比較テスト： ...

Docker がプライベート CA（例：step-ca）で発行した HTTPS 証明書を使用する場合、Docker Engine によるイメージの pull と コンテナ内のアプリケーションによる HTTPS アクセス の 2 つの状況を区別する必要があります。両者の証明書信頼ストアが同じとは限りません。 一、Docker Engine でプライベート CA を信頼する docker login、docker pull、docker push でプライベートレジストリにアクセスする場合に適用されます。 指定した Registry のみを信頼する（推奨） Registry のアドレスが registry.example.com:5000 であるとします。 sudo mkdir -p /etc/docker/certs.d/registry.example.com:5000 sudo cp root_ca.crt /etc/docker/certs.d/registry.example.com:5000/ca.crt ディレクトリ名は、実際にアクセスする Registry のホスト名とポートに一致させる必要があります。デフォルトの HTTPS 443 ポートは通常省略できます。ca.crt は PEM 形式の CA 証明書にし、私鍵にしないでください。 確認： docker login registry.example.com:5000 Ubuntu / Debian ホスト全体で信頼する sudo cp root_ca.crt /usr/local/share/ca-certificates/my-root-ca.crt sudo update-ca-certificates Linux 上では、Docker は通常ホストのシステム CA 信頼ストアを使用します。通常 Docker を再起動する必要はありません。それでも有効にならない場合は、Docker のログと証明書設定を確認してから、再起動するかどうかを決めてください（再起動すると実行中のコンテナに影響する可能性があります）。 ...

Linux バイパスルーター上で UFW と sing-box TUN を同時に実行すると、誤診しやすい障害が発生することがあります。sing-box 自体は正常に動作しているのに、LAN 上のデバイスがバイパスルーター経由でインターネットにアクセスできない状態です。その時点で遮断されていた TCP ポートを許可したとしても、sing-box を再起動すると問題が再発することがあります。 本稿では、実際に観察された原因と、回帰検証待ちの修復方法を記録します。例はすべて文書予約アドレスを使用し、実際のネットワークには対応していません。 環境と症状 Linux バイパスルーター。LAN インターフェースは eth0、アドレスは 192.0.2.1（例示のみ）。 下流端末 192.0.2.20 は、IPv4 ゲートウェイとしてバイパスルーターを使用します。 sing-box の TUN インターフェース名は tun0 で、auto_route と auto_redirect を有効にしています。 UFW は既定で、許可されていない着信トラフィックを拒否します。 sing-box の主要設定： { "type": "tun", "interface_name": "tun0", "auto_route": true, "auto_redirect": true } 障害発生中のログは次のようなものです： [UFW BLOCK] IN=eth0 OUT= SRC=192.0.2.20 DST=192.0.2.1 PROTO=TCP DPT=24461 SYN DPT=24461 は一度の実行で観察された動的ポートにすぎないため、UFW に固定して書き込むべきではありません。OUT= が空であることから、このパケットは FORWARD 経路を通るだけでなく、本機の INPUT 経路に入り込んでいることが示唆されます。 NAT リダイレクトの追跡 sing-box の待ち受けを確認します： sudo ss -lntup | grep sing-box nftables を確認します： ...

CrowdSec を使って Debian サーバーで悪意ある IP を自動ブロックする 公開サーバーは毎日、さまざまな自動スキャンに遭遇します。 サービスを意図的に公開していなくても、SSH ポートには root、admin、test などのユーザー名に対するログイン試行が日常的に届きます。Web サービスでは .env、wp-admin、phpinfo.php などのパスに対する探索が行われます。 これらのリクエストの多くは自動化されたスキャナによるものです。実際の侵入に至るとは限りませんが、意味のないログを大量に発生させ、サービスの露出面（attack surface）を拡大させます。 静的なファイアウォールルールだけでは、攻撃の挙動に応じてブロック対象リストを動的に調整することが困難です。 そこで私は CrowdSec を試してみることにしました。サーバーログから悪意ある挙動を識別し、nftables と連携して攻撃元の IP を自動的にブロックします。 本稿では、Debian 12 への CrowdSec の導入手順と、それが「ある IP をブロックすべきかどうか」をどのように判断するかを記録します。 1. CrowdSec とは？ CrowdSec はオープンソースの侵入検知・セキュリティレスポンスシステムです。 SSH や Web サーバーなどが生成するログを分析し、総当たり攻撃（ブルートフォース）、脆弱性スキャン、悪意あるクローラーなどの挙動を検知します。 従来の静的な IP ブラックリストとは異なり、CrowdSec は主に挙動の特徴に基づいてブロックすべきかどうかを判断し、コミュニティの脅威インテリジェンスも利用できます。 CrowdSec の処理は 2 つに分かれます。 Security Engine：ログを読み込み、攻撃を識別し、ブロック判定を生成します。 Remediation Component（Bouncer）：ブロック判定を実行します。たとえばファイアウォールルールを変更します。 この 2 つは互いに独立しています。 つまり、CrowdSec の Security Engine だけを導入しても、ネットワーク接続が自動的にブロックされるわけではありません。 1.1 処理の流れ SSH / Caddy / Nginx | v Application Logs | v CrowdSec Parser | v Detection Scenarios | v Security Alerts | v Decision Profiles | v Local API | v Firewall Bouncer | v nftables | v Block IP ログ分析とファイアウォールの実行を切り離しているため、単一サーバーでも、中央 API を通じて複数サーバーにブロック判定を配信する場合でも同じように機能します。 ...