Nftables

小規模なメモリの Debian サーバーでは、以前 CrowdSec を使って SSH と Web のログを解析し、Firewall Bouncer を通じて封禁の決定を nftables に同期していました。 この構成は攻撃nese behaviorに応じて IP を動的に封禁できますが、メモリが数百 MiB しかなく、複数の個人용サービスを実行しているサーバーでは、リソースのトレードオフを再検討する必要があります。最終的には次の構成を採用しました。 Web：Caddy の GeoIP と手動 IP ホワイトリストを使用し、サイトごとに CDN からのオリジン接続を許可するかどうかを選択します。 SSH：Fail2ban が systemd journal を読み取り、異常な送信元を nftables で封禁します。 本稿では、改造の全体手順と、導入時に発生したログソースおよび起動順序の問題を記録します。すべてのドメイン、アドレス、ホスト識別子には例示用の値に置き換えています。コマンドは root ユーザーで実行します。 一、先に保護機能の変化を整理する 項目 旧構成 新構成 Web アクセス制御 CrowdSec がログを解析し、封禁の決定を生成 Caddy が送信元の地域または IP に応じて許可 SSH の異常ログイン CrowdSec の SSH シナリオ Fail2ban の SSH jail Web の挙動検知 導入済みの Collection と Scenario 次第 本稿では維持していません コミュニティの脅威インテリジェンス CrowdSec のコミュニティリストを使用可能 本稿では接続していません Web リクエストの拒否段階 Firewall Bouncer のファイアウォールルール Caddy の HTTP リクエスト処理段階 地域ホワイトリストは、挙動検知と同等の代替にはなりません。許可された地域からの悪意あるリクエストもアプリケーションに到達する可能性があります。また、Caddy の GeoIP ルールは、Caddy を通過しない他の公開ポートには適用されません。 ...

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 比較テスト： ...

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 を通じて複数サーバーにブロック判定を配信する場合でも同じように機能します。 ...