デモ
何をするか
普通の訪問者に出すのは、自動で終わる PoW (proof-of-work) だけ。クリックもパズルも要らず、一度通れば署名付き cookie で数日間そのまま通れる。自動化の気配があるアクセスや、自分で決めたルール (ネットワーク・国・リクエスト数) に当たったアクセスは、unmask 自前の行動分析 CAPTCHA に進む。外部の CAPTCHA サービスも site key も要らず、データも外に出ない。遮断するのは、自分で遮断を選んだところだけ。challenge ページには自サイトのロゴが入り、訪問者の言語で表示される。
PoW → 行動分析 CAPTCHA → 遮断は選んだときだけ · 外部の CAPTCHA サービスは不要
Googlebot / Bingbot / GPTBot / ClaudeBot などの検索・AI クローラーは既定ではすべて通過するので、検索順位の事故を起こさない安全側から始まる。公式 IP レンジを公開しているベンダーのクローラーはアドレスで本物を確かめるため、名前だけを借りたなりすましは、ほかの訪問者と同じく challenge される。600 以上のパターンを組み込み済みで、AI 学習用のクローラーだけをワンクリックで断り、AI 検索の取得は通したままにできる。クローラーを 1 つずつ通す / challenge することもできる。
既定 = 検索順位の事故ゼロ · AI 学習は断り AI 検索は通す、をワンクリックで
JA4 fingerprint は、TLS handshake から取り出すアクセス元の「指紋」だ。IP・国・VPN・User-Agent ではなく、使っているツール (curl や python のプログラム、ヘッドレスブラウザなど) に付いてくる。unmask はこの指紋そのものを BAN できるので、アドレスを替えても BAN は外れない。JA4 は何層もある判定の一つで、ネットワーク (ASN)・国・リクエスト数・honeypot・共有 BAN リストと組み合わせて使う。どのルールも管理画面から数クリックで設定できる。
指紋・ネットワーク・国・リクエスト数・honeypot・共有 BAN を重ねて判定
nginx では、一度通過した訪問者 (cookie を持つ再訪) の検証が nginx のワーカー内だけで完結する。サブリクエストも追加のホップもないので、アクセスの多いサイトの入口にもそのまま置ける。nginx 以外のサーバーにはgateway コンテナを使う。nginx と module と daemon を 1 つのイメージにまとめてあり、docker run 1 回、または compose の service 1 つで、Apache や Node など、どんな HTTP サーバーの前にも置ける。
nginx の dynamic module · 1 コンテナの gateway
unmask が落ちても nginx は止まらない。通過済みの訪問者は cookie 検証だけの速い経路を保ち、まだ通過していない訪問者にも PoW / CAPTCHA は出ず、目的のページがそのまま表示される (unmask を入れていないときと同じ動きに自動で戻る)。「守りは落ちても web は動き続ける」を既定にし、深夜の障害でサイトごと落ちる事故を、仕組みとして防ぐ。
どの導入形態でも既定で fail-open
すべて自社のサーバーで動き、管理画面 1 つで運用できる。ダッシュボード、各リクエストが challenge された理由の分かるログ、ワンクリックの BAN まで揃っている。challenge 判定・cookie・IP・JA4・イベントログは自分のサーバー内で完結し、利用者の行動が外部の SaaS に漏れることはない。特定ベンダーへの縛りもなく、GDPR や個人情報保護法との整合も、自社のポリシーで取れる。
既定では訪問者のデータを外部に送らない・第三者 SaaS との委託契約も不要
誰の何を守るか
wp-login.php / .env / xmlrpc.php や既知 CVE の path を
機械的に舐める 脆弱性スキャナや攻撃 bot の多くは、ブラウザを使わないツールから来る。
unmask は入口で、TLS 指紋・ネットワーク・リクエスト数・honeypot を重ねた判定と PoW / CAPTCHA でこれらをふるい落とす。
ブラウザで通過したアドレスでも、取れる量には上限があり、超えると CAPTCHA か拒否に切り替わる。
AI で脆弱性の探索や攻撃が安く・速くなっても、大量の自動アクセスにはコストを課し続けられるので、
自動化された探索を入口の段階で抑えられる。
攻撃の試行が減れば、突破と情報漏えいのリスクも下がる · 深層防御の一層として
アクセスの急増や、同じ相手からの集中した攻撃、公開データの大量の持ち去りは、ダッシュボードと統計にすぐ表れる。 どこから (国・ASN)・どんなクライアント (JA4・UA) が来て、何をどれだけ止めたかが、30 日の推移まで見える。 challenge の急増やハニーポットでの BAN は、メールや webhook (Slack・Discord など) への通知で知ることもできる。 hunt 画面で相手を確かめたら、その場で指紋の BAN やネットワーク (ASN) へのルールを掛けられる。
気づくのが早ければ、手を打つのも早くなる · 別の監視ツールなしで
bot 対策の主流は SaaS 型、つまり すべての通信をベンダーの基盤に通す前提だ。 訪問者の TLS handshake は自社サーバーではなくベンダーと結ばれ、 復号された通信を第三者が扱うことになるため、プライバシー・コスト・ベンダー障害の波及といった問題を抱える。 unmask は 既存の httpd に include を数行足すだけで、 TLS handshake は訪問者と自社サーバーのあいだで完結する。前段に何も置かないか、置くとしても自社のコンテナだけ。既定では訪問者のデータを外部に送らない。
データ主権・プライバシー・OSS であることを要件にする組織 (規制業界 / 公共 / 自社運用) に。導入も撤去も設定数行で済む